[Serusers] 200 OK/SDP and ACK/SDP problem
Carla Ares
carla.ares at gmail.com
Wed Feb 1 14:58:16 CET 2006
Sides A (the origin of the call), cannot send the SDP in the INVITE, because
it does not know the rtp information until the destination confirms his rtp
info.
This cannot be done in another way, because H323 (slow start) works in that
way.
On 2/1/06, Voipers Portugal <voipers at gmail.com> wrote:
>
> Why don't you send SDP in the INVITE message?
>
> Jose Simoes
>
>
> On 2/1/06, Carla Ares <carla.ares at gmail.com> wrote:
>
> > Hi all,
> >
> > > I have a problem with audio, when the destination of a call is natted
> > > and the other side is public. This problem is cause because the SDP info
> > > only is present in the 200 OK and in the ACK message.
> > >
> > > I'm using ser ( 8.14) with mediaproxy (1.2.1).
> > >
> > > I have an H323 to SIP translator (and SIP to H323 too) connected to
> > > the PSTN and to the SIP Proxy (SER).
> > > H323 is the origin of the call (public client), and SIP UAC is the
> > > destination (Natted client).
> > > My proxy is working in state full mode and has a public IP.
> > >
> > > The H323 side is using slow start, so when it starts the transaction
> > > with an INVITE, it will not send the SDP info (it will send it in the ACK
> > > message).
> > > The proxy forwards this message to the destination.
> > > SIP UAC, starts ringing. When we hooks off, the SIP UAC send an 200 OK
> > > with SDP message to the H323 side.
> > >
> > > This is the 200 OK / SDP that the proxy receives from the SIP side.
> > >
> > > No. Time Source Destination
> > > Protocol Info
> > > 488 28.488811 200.68.89.2 200.68.89.12
> > > SIP/SDP Status: 200 OK, with session description
> > > Message body
> > > Session Description Protocol
> > > Session Description Protocol Version (v): 0
> > > Owner/Creator, Session Id (o): 700600 6015 6015 IN IP4
> > > 192.168.0.101
> > > Owner Username: 700600
> > > Session ID: 6015
> > > Session Version: 6015
> > > Owner Network Type: IN
> > > Owner Address Type: IP4
> > > Owner Address: 192.168.0.101
> > > Session Name (s): AddPac Gateway SDP
> > > Connection Information (c): IN IP4 192.168.0.101
> > > Connection Network Type: IN
> > > Connection Address Type: IP4
> > > Connection Address: 192.168.0.101
> > > Time Description, active time (t): 0 0
> > > Session Start Time: 0
> > > Session Stop Time: 0
> > > Media Description, name and address (m): audio 23018
> > > RTP/AVP 18 8 0 101
> > > Media Type: audio
> > > Media Port: 23018
> > > Media Proto: RTP/AVP
> > > Media Format: ITU-T G.729
> > > Media Format: ITU-T G.711 PCMA
> > > Media Format: ITU-T G.711 PCMU
> > > Media Format: 101
> > >
> > > Following the ser.cfg, this 200 OK / SDP will make the proxy to use
> > > mediaproxy (use_media_proxy()), because the destination user is natted. So
> > > the mediaproxy module, will generate a lookup command to the
> > > proxydispatcher.py.
> > >
> > > proxydispatcher[30535]: command lookup 2281401749 at 200.68.89.10
> > > 192.168.0.101:23018:audio 200.68.89.2 200.68.89.10 remote 200.68.89.10unknown AddPac=20SIP=20Gateway info=
> > > from:1150316660 at 200.68.89.10, to:1152464490 at 200.68.89.10
> > > ,fromtag:3512844671,totag:7b07717a4
> > > proxydispatcher[30535]: warning: trying to lookup session with
> > > non-existent id: ' 2281401749 at 200.68.89.10'
> > >
> > > The proxydispatcher does not recognize that command because it has not
> > > generate the session before. So, the proxy forwards the 200 OK /SDP message
> > > without changing the SDP info. When the H323 sides receives that info, it
> > > thinks that it has to send RTP to the private IP.
> > >
> > > Then the H323 sends the ACK with SDP.
> > >
> > > Then, we cannot ear audio in both sides.
> > >
> > > Here is the problem, because, I didn't receive an INVITE with SDP that
> > > can create the session into the dispatcher.
> > >
> > >
> > > A is public, B is natted
> > >
> > > side A Proxy side B
> > >
> > > INVITE without SDP
> > > ---------->
> > > 100 Trying
> > > <----------
> > >
> > > INVITE without SDP
> > > ---------->
> > >
> > > 100 Trying
> > > <----------
> > > 180 Ringing
> > > <----------
> > > 180 Ringing
> > > <----------
> > >
> > > 200 OK SDP (B private IP)
> > > <----------
> > > *1*
> > > 200 OK SDP (B private IP)
> > > <----------
> > >
> > > ACK SDP (A public IP)
> > > ---------->
> > > *2*
> > > ACK SDP (mediaproxy public IP)
> > > ---------->
> > >
> > > ......................................................
> > > RTP from B
> > > <----------------------
> > > *3*
> > > ......................................................
> > >
> > >
> > > *1* The proxy must replace the private IP of the SDP, with the ip of
> > > the mediaproxy. The looku prequest does not work, because no session was
> > > found
> > > *2* the proxy generates the session in the mediaproxy. So B thinks
> > > that the RTP must go to the mediaproxy. But A never knows the mediaproxy
> > > address.
> > > *3* RTP from A goes to anywhere, because A does not know where it is
> > > the private adrress of B.
> > >
> > >
> >
> > Do you know a solution to this? Is the sequence of the message all
> > right?
> >
> >
> > Regards.
> > Carla
> >
> >
> >
> >
> > _______________________________________________
> > Serusers mailing list
> > serusers at lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060201/3c91e703/attachment.htm>
More information about the sr-users
mailing list