process of connecting RTP with SIP via SDP & land lines

I have a problem with starting a media session and to combine it with my SIP client. I've designed a recursive SIP client that reuse the same request template to send the next requests to server, according to the acceptable sequences noted in the RFC's, and examples that I read. as far as I could tell the SIP part is working fine registers to server invites, and authenticates. I didn't complete any calls to clients yet because of the content header needs to be filled up (which I didn't yet so I get a 503 from the server which is O开发者_StackOverflowK I guess).

for a long time I didn't know where to start with the media session, and slowly learned how to use the JMF and I've constructed an object that handles RTP transmitting, now I'm standing at the cross road, on the one hand I have my SIP signaling but it needs the SDP content header to complete the invite, and on the other I have the RTP which is knows how to p2p.

For me to complete my design I require your help with the following questions:

1. Is there an easy//a simple//an implemented way to convert the Audio/Video format from the JMF into SDP media headers? or even a generator that I would input all the parameters for the content header, and it would generate a content header fast, or do I have to implement this myself?

2. Once I've finished constructing the SDK and the SIP is up and running and I get an OK response from the server (after ringing and all), how do I start the media session? do I connect p2p according to caller details I send in the SIP invite?

3. If 2 is correct, then how does a connection to land lines would be? does land lines knows that once they send an OK back to server they listen/start RTP session on a specific port?

Or did I get everything wrong? :-/

I really appreciate any help I could I get, I looked every where for answers but they are not clear, they ignore question 2 as if it was an obvious thing, but for me it just isn't.

Thank in advance, Adam Zehavi.

Added:

First thank you for you response and the time you take to help me.

I'll go back to question 2:

once you get an Ok response you will know the IP socket(you mean the ADDRESS:PORT correct?) that the SIP user agent server (UAS) is listening on and the codecs it accepts and can start sending your RTP.

Ok that I understand, I wanted to know another thing, during this conversation time that I send RTP packet to the UAS, the UAS uses as a bridge between both UAC's.

Now... could I instantiate the conversation using SIP, and then send the clients information from one to the other and establish P2P between two computer, without any middleman(UAS), and then dispose of the SIP session?

I hope I explained my self better now...

Thanks, Adam.

For 1, I don't know anything about JMF so can't answer directly but SDP is not actually a complicated standard, unlike SIP which is, so constructing an SDP packet shouldn't be that difficult. The minimum you need to build an SDP packet are the codecs you're offering and the IP socket you're accepting the RTP on.

For 2, once you get an Ok response you will know the IP socket that the SIP user agent server (UAS) is listening on and the codecs it accepts and can start sending your RTP. At the same time you should start receiving RTP from the UAS as it will start sending at the same time it sends the Ok. Of course you will also need to send a SIP ACK request in response to the Ok response otherwise some UAS's will assume the response did not get through and after some time will terminate the call. If you're just starting to write your own SIP stack there's still a long way to go!

For 3, yes, although by landlines you really mean a SIP-to-PSTN gateway (the PSTN side will be something like ISDN, SSL or analogue). The SIP side of the PSTN gateway is the same as any other SIP UAS and once it accepts an INVITE request it will start sending RTP tp the socket specified in the request and likewise will start listening for RTP on the socket it has placed in the Ok response that will be sent back to your SIP client.

Update

Now... could I instantiate the conversation using SIP, and then send the clients information from one to the other and establish P2P between two computer, without any middleman(UAS), and then dispose of the SIP session?

The answer is yes but you are confusing the terminology a little bit. An established SIP call is known as a session and is always between a User Agent Client (UAC) and a User Agent Server (UAS). Every SIP agent is supposed to be capable of acting in either role as a UAC or UAS and the main difference between the two roles is that a UAC intiates the call and the UAS answers it. A particular SIP device will be in a UAC role for calls it initiates and a UAS role for calls it answers.

Why is this UAC and UAS description relevant? Because all SIP communications are peer-to-peer. SIP is NOT a client/server protocol. It's a peer-to-peer protocol. Now it does get confusing because you'll have VoIP providers that operate SIP Proxy Servers or SIP PSTN Gateways which make it seem as if SIP does operate on a client-server model but it doesn't.

So I think the question you are actually wanting to ask is can a SIP call between a UAC-to-B2BUA-to-UAS (which is actually two separate calls or SIP sessions: UAC-to-UAS/UAC-to-UAS) have the media bypass the B2BUA and instead travel directly between the UAC and UAS at either end. The answer to that question is yes. A B2BUA like Asterisk has a SIP configuration option called canreinvite which if set to yes will result in it sending re-INVITEs to either end of the call once it's answered to get the RTP to flow directly between the call endpoints rather than being bridged through itself, of course if codec transcoding, recording or an equivalent feature is required it will not attempt the re-INVITE. A different approach is a traditional SIP Proxy approach such as used by OpenSER where it's not designed to bridge media at all and all calls through it will always result in the RTP being directly between the SIP devices at either end of the call. The way that works is OpenSER will simply forward the request it receives from the UAC through to the UAS and apart from adding and/or modifying an extra SIP header or two the INVITE request is exactly as if the UAC had sent it directly to the UAS.

All clear as mud? Here's some links to further reading that will help you.

Tech-invite - very good examples of SIP scenarios,

RFC5359 Session Initiation Protocol Service Examples - more examples,

SIP Sorcery forums - forum site for a public service I run which is frequented by a few people knowledgeable on SIP matters if you should have more in depth SIP questions.