incoming call problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Maya

it looks like this is a negotiation problem with G729 annex b. the incoming
call is requesting annex b=yes, you are responding with annex b=no.
therefore, codec negotiation fails and you don't get ACK. I am using ACME
packet as well and it works fine for me. You just need to make a decision if
you want to support VAD, then turn it on. Otherwise inform your carrier to
only use G729a (i.e without VAD). Hope this helps.

Alex

On Thu, Mar 4, 2010 at 9:15 AM, <pjsip-request at lists.pjsip.org> wrote:

> Send pjsip mailing list submissions to
>        pjsip at lists.pjsip.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
> or, via email, send a message with subject or body 'help' to
>        pjsip-request at lists.pjsip.org
>
> You can reach the person managing the list at
>        pjsip-owner at lists.pjsip.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of pjsip digest..."
>
>
> Today's Topics:
>
>   1.  incoming call problem (alex vishnev)
>   2. Python PSJUA.py - adding headers don't work (Peuralahti Jari)
>   3. Re: incoming call problem (Maya Zalcberg)
>   4. Re: incoming call problem (nir elkayam)
>   5. Re: incoming call problem (Maya Zalcberg)
>   6. Re: incoming call problem (nir elkayam)
>   7. Re: incoming call problem (Maya Zalcberg)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 3 Mar 2010 13:30:16 -0500
> From: alex vishnev <alex9134@xxxxxxxxx>
> To: pjsip at lists.pjsip.org
> Subject:  incoming call problem
> Message-ID:
>        <11dbbfc81003031030v5464fb65s91f6a2b03ab9c02c at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> >
> > Maya
> >
>
> i would make sure that you are responding with 200OK and SDP matching the
> incoming order. It is invalid to change the codec order. You can remove the
> codecs you don't support, but you can't change the order. Some UA or UAS
> will silently drop your 200OK and will not send/forward ACK to you. If you
> get incoming call with codec payload: 0 4 6 18 101, and you don't support
> 18
> (G729), it is ok to reply with 200OK as 0 4 6 101. However, if you respond
> with 6 18 0 4 101 it is not valid. this is a common mistake i have seen in
> many implementations. I use the same platform as you, but i don't have the
> same problem. Therefore, i would carefully examine what you are responding.
> Wireshark or other traces will certainly help into troubleshooting your
> issue.
>
> Alex
>
> >
> > Message: 1
> > Date: Wed, 3 Mar 2010 14:27:34 +0200
> > From: Maya Zalcberg <maya@xxxxxxxxxxx>
> > To: pjsip at lists.pjsip.org
> > Subject: incoming call problem
> > Message-ID:
> >        <a87a8ade1003030427x53f3155dq38f4b92f62314711 at mail.gmail.com>
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > Hi,
> > I am using the latest version of pjsip (1.5.5) for iPhone 3.2.1.
> > The codec i prefer to use is G729 (although i can also work with others,
> > like G711_ULAW or G711_ALAW).
> > It works fine when my client is initiating the call.
> > The problem is when my client receives an incoming call. The client gets
> > the
> > invite request and answers with 200OK. Consequently, the user that
> > initiated
> > the call thinks that the call is initiated successfully, and sends to my
> > client ACK (to the right port).He continues sending RTP, but my client
> > doesn't get the  ack, and I guess still waits for the call to be
> confirmed
> > by the other side. As a result there is no voice on my client's end (even
> > though rtp is being sent to it's port). Obviously,  the other side
> doesn't
> > get any voice either. Because my client for some reason doesn't realize
> he
> > got the ACK notification, he keeps sending  200OK to the other side.
> >
> > Thanks,
> > Maya
> >
> > --
> > Maya Zalcberg
> > www.zemingo.com
> > 972523328356
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> >
> http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20100303/ed3c73bc/attachment-0001.html
> > >
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20100303/9ace008d/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Thu, 4 Mar 2010 10:54:12 +0200
> From: Peuralahti Jari <Jari.Peuralahti@xxxxxxxx>
> To: "pjsip at lists.pjsip.org" <pjsip at lists.pjsip.org>
> Subject: Python PSJUA.py - adding headers don't work
> Message-ID:
>        <0F6023935199524394B320D339508C059790CB0188 at SECU003.acc.master.epnet
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
>
>
>
>
> In the pjsua documentation http://www.pjsip.org/python/pjsua.htm#Buddy
>
> is written that optional headers can be added using hdr_list:
>
> send_pager(self, text, im_id=0, content_type='text/plain',
> hdr_list=None)
>    Send instant message to remote buddy.
>
>    Keyword arguments:
>    text         -- Instant message to be sent
>    im_id        -- Optional instant message ID to identify this
>                    instant message when delivery status callback
>                    is called.
>    content_type -- MIME type identifying the instant message
>    hdr_list     -- Optional list of headers to be sent with the
>                    request.
>
> how ever I have not applied get to this work right.
>
> This is what I have tryed
>    header_list = []
>    header_list.append("Subject=Test")
>    header_list.append('Subject: Foo')
>    header_list.append('Subject:, foo')
>    ... some code
>
>
>
> buddy.send_pager(input,content_type='text/plain',hdr_list=header_list)
>
> and for result I get SIP MESSAGE with basic headers, but none
> of my optional headers except four ":" empty lines:
>
> MESSAGE sip:jari at mydomain.fi <sip%3Ajari at mydomain.fi> SIP/2.0.
> Via: SIP/2.0/UDP
> myip:5080;rport;branch=z9hG4bKPjRT8HRroNeYqMblLt8bxfSxI7rDfAUZR4.
> Max-Forwards: 70.
> From: <sip:jari@xxxxxxxxxxx <sip%3Ajari at mydomain.fi>
> >;tag=Rro.mo0pMTmkoiS8cAs74ELT4X.eve98.
> To: <sip:jari at mydomain.fi <sip%3Ajari at mydomain.fi>>.
> Call-ID: gA5YAVKuj-jRmVItXv.qE9VwM4dPpODt.
> CSeq: 63465 MESSAGE.
> Accept: text/plain, application/im-iscomposing+xml.
> Contact: <sip:jari at myip.fi:5080>.
> User-Agent: Jari's Python Script.
> : .
> : .
> : .
> : .
> Route: <sip:sip.mydomain.fi;lr>.
> Proxy-Authorization: Digest username="jari",
> realm="mydomain.fi",
> nonce="4b8e859d000005f04bf656f8fdd980b78d865ef27632a8e9",
> uri="sip:jari at mydomain.fi <sip%3Ajari at mydomain.fi>",
> response="a94938b0df8be6c407d95d93e5aa02d1",
> cnonce="0u45VvJKoydngfonnRbaapVgvuIhr.00", qop=auth, nc=00000001.
> Content-Type: text/plain.
> Content-Length:    12.
> .
> TEST MESSAGE
> -------------------------
>
> What I am doing wrong or isit a bug?
>
> Cheers,
>
> Jari
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 4 Mar 2010 14:55:17 +0200
> From: Maya Zalcberg <maya@xxxxxxxxxxx>
> To: pjsip list <pjsip at lists.pjsip.org>
> Subject: Re: incoming call problem
> Message-ID:
>        <a87a8ade1003040455j12b787d4y3e3a7df906037718 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Alex,
> Thanks for the answer.
> As mentioned before, i don't think that the problem is with the codecs
> (because i already tried it when both sides supported only one codec which
> was G729).
> maybe the audio device is just not running well (even though it has been
> opened correctly,
> according to the log). I will check if  the record and playback callbacks
> of
> the sound device are being called. did you implement these callbacks
> yourself?
>
> Best regards,
>
> Maya
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20100304/274a6ce9/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Thu, 4 Mar 2010 15:00:56 +0200
> From: nir elkayam <nir.elkayam@xxxxxxxxx>
> To: pjsip list <pjsip at lists.pjsip.org>
> Subject: Re: incoming call problem
> Message-ID:
>        <385218e21003040500g57a9fc3agb18d33d63301ff02 at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> maybe its relate to NAT issues?
> from the iphone which is behaind NAT you call to public IP?
>
> On Thu, Mar 4, 2010 at 2:55 PM, Maya Zalcberg <maya at zemingo.com> wrote:
>
> > Hi Alex,
> > Thanks for the answer.
> > As mentioned before, i don't think that the problem is with the codecs
> > (because i already tried it when both sides supported only one codec
> which
> > was G729).
> > maybe the audio device is just not running well (even though it has been
> > opened correctly,
> > according to the log). I will check if  the record and playback callbacks
> > of the sound device are being called. did you implement these callbacks
> > yourself?
> >
> > Best regards,
> >
> > Maya
> >
> >
> >
> > _______________________________________________
> > Visit our blog: http://blog.pjsip.org
> >
> > pjsip mailing list
> > pjsip at lists.pjsip.org
> > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
> >
> >
>
>
> --
> ??? ??????
> ??: 050-3930056
> nir.elkayam at gmail.com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20100304/b4eb8178/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 5
> Date: Thu, 4 Mar 2010 15:31:46 +0200
> From: Maya Zalcberg <maya@xxxxxxxxxxx>
> To: pjsip list <pjsip at lists.pjsip.org>
> Subject: Re: incoming call problem
> Message-ID:
>        <a87a8ade1003040531s6fadab98s4a264db042088cdd at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Nir,
> I use SBC, (ACME PACKETS) which handle these scenarios of NAT.
> When i use  soft phone in the same network with the same network topology
> everything  works fine and i don't even need the use of a STUN. So
> unfortunately i don't think the problem is the NAT.
> Maybe you can think of another reason..?
>
> Regards,
> Maya
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20100304/acd842ed/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 6
> Date: Thu, 4 Mar 2010 15:57:25 +0200
> From: nir elkayam <nir.elkayam@xxxxxxxxx>
> To: pjsip list <pjsip at lists.pjsip.org>
> Subject: Re: incoming call problem
> Message-ID:
>        <385218e21003040557g21a69d9bh91130d041cb4e652 at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> maybe you can add the log file from the phone..
>
> On Thu, Mar 4, 2010 at 3:31 PM, Maya Zalcberg <maya at zemingo.com> wrote:
>
> > Hi Nir,
> > I use SBC, (ACME PACKETS) which handle these scenarios of NAT.
> > When i use  soft phone in the same network with the same network topology
> > everything  works fine and i don't even need the use of a STUN. So
> > unfortunately i don't think the problem is the NAT.
> > Maybe you can think of another reason..?
> >
> > Regards,
> > Maya
> >
> > _______________________________________________
> > Visit our blog: http://blog.pjsip.org
> >
> > pjsip mailing list
> > pjsip at lists.pjsip.org
> > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
> >
> >
>
>
> --
> ??? ??????
> ??: 050-3930056
> nir.elkayam at gmail.com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20100304/8db73d7c/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 7
> Date: Thu, 4 Mar 2010 16:15:18 +0200
> From: Maya Zalcberg <maya@xxxxxxxxxxx>
> To: pjsip list <pjsip at lists.pjsip.org>
> Subject: Re: incoming call problem
> Message-ID:
>        <a87a8ade1003040615j3796142av6e905ff15c04737b at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
> I've already tried to upload it to here, so for now i will just copy the
> log.
>
> --end msg--
>  19:52:35.236    pjsua_app.c  Call 0 is DISCONNECTED [reason=200 (Normal
> call clearing)]
>  19:52:35.272  pjsua_media.c  Media session for call 0 is destroyed
>  19:52:36.271  pjsua_media.c  Closing sound device after idle for 1 seconds
>  19:52:36.271  pjsua_media.c  Closing iPhone Sound Device sound playback
> device and iPhone Sound Device sound capture device
>  19:52:59.091   pjsua_core.c  RX 823 bytes Request msg
> INVITE/cseq=225308893
> (rdata0x84d064) from UDP 80.179.0.4:5060:
> INVITE sip:722511874 at 192.168.1.59:5060 SIP/2.0
> Via: SIP/2.0/UDP 80.179.0.4:5060;branch=z9hG4bKgqo3mo00d0b10koup7c0.1
> From: "a 1"<sip:1867@xxxxxxxxxxx <sip%3A1867 at 072.012.net> <
> sip%3A1867 at 072.012.net <sip%253A1867 at 072.012.net>>
> ;user=phone>;tag=SD1m0gd01-1080909488-1267465970104-
> To: "a 1"<sip:722511874 at 072.012.net <sip%3A722511874 at 072.012.net> <
> sip%3A722511874 at 072.012.net <sip%253A722511874 at 072.012.net>>>
> Call-ID: SD1m0gd01-cbf46a742831cc7b6fa4564187179755-06al420
> CSeq: 225308893 INVITE
> Contact: <sip:1867 at 80.179.0.4:5060;transport=udp>
> Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY
> Accept: multipart/mixed,application/media_control+xml,application/sdp
> Supported:
> Max-Forwards: 4
> Content-Type: application/sdp
> Content-Length: 227
>
> v=0
> o=BroadWorks 162350108 1 IN IP4 212.199.138.8
> s=-
> c=IN IP4 212.199.138.8
> t=0 0
> m=audio 21758 RTP/AVP 18 101
> a=fmtp:18 annexb=yes
> a=fmtp:101 0-15
> a=rtpmap:18 G729/8000
> a=rtpmap:101 telephone-event/8000
> a=sendrecv
>
> --end msg--
>  19:52:59.092  pjsua_media.c  Media index 0 selected for call 1
>  19:52:59.094   pjsua_core.c  TX 344 bytes Response msg
> 100/INVITE/cseq=225308893 (tdta0x869c00) to UDP 80.179.0.4:5060:
> SIP/2.0 100 Trying
> Via: SIP/2.0/UDP 80.179.0.4:5060
> ;received=80.179.0.4;branch=z9hG4bKgqo3mo00d0b10koup7c0.1
> Call-ID: SD1m0gd01-cbf46a742831cc7b6fa4564187179755-06al420
> From: "a 1" <sip:1867@xxxxxxxxxxx <sip%3A1867 at 072.012.net> <
> sip%3A1867 at 072.012.net <sip%253A1867 at 072.012.net>>
> ;user=phone>;tag=SD1m0gd01-1080909488-1267465970104-
> To: "a 1" <sip:722511874 at 072.012.net <sip%3A722511874 at 072.012.net> <
> sip%3A722511874 at 072.012.net <sip%253A722511874 at 072.012.net>>>
> CSeq: 225308893 INVITE
> Content-Length:  0
>
>
> --end msg--
>  19:52:59.104  pjsua_media.c  Opening sound device PCM at 16000/1/20ms
>  19:52:59.235     ec0x24d100  Echo suppressor created, clock_rate=16000,
> channel=1, samples per frame=320, tail length=200 ms, latency=140 ms
>  19:52:59.459   conference.c  Port 2 (ring) transmitting to port 0 (iPhone
> Sound Device)
>  19:52:59.468    pjsua_app.c  Incoming call for account 2!
> From: "a 1" <sip:1867@xxxxxxxxxxx <sip%3A1867 at 072.012.net> <
> sip%3A1867 at 072.012.net <sip%253A1867 at 072.012.net>>;user=phone>
> To: "a 1" <sip:722511874 at 072.012.net <sip%3A722511874 at 072.012.net> <
> sip%3A722511874 at 072.012.net <sip%253A722511874 at 072.012.net>>>
> Press a to answer or h to reject call
> 2010-03-01 19:52:59.498 MySIPhoneV2[1527:207] Could not load the "siax.png"
> image referenced from a nib in the bundle with identifier
> "com.zemingo.MySIPhoneV2"
>  19:53:00.564   strm0x871b74  VAD temporarily disabled
>  19:53:00.565   strm0x871b74  Encoder stream started
>  19:53:00.565   strm0x871b74  Decoder stream started
>  19:53:00.565  pjsua_media.c  Media updates, stream #0: G729 (sendrecv)
>  19:53:00.566   conference.c  Port 2 (ring) stop transmitting to port 0
> (iPhone Sound Device)
>  19:53:00.566   conference.c  Port 3
> (sip:1867 at 072.012.net <sip%3A1867 at 072.012.net><sip%3A1867 at 072.012.net<sip%253A1867 at 072.012.net>
> >;user=phone)
> transmitting to port 0 (iPhone Sound Device)
>  19:53:00.566   conference.c  Port 0 (iPhone Sound Device) transmitting to
> port 3 (sip:1867 at 072.012.net <sip%3A1867 at 072.012.net> <
> sip%3A1867 at 072.012.net <sip%253A1867 at 072.012.net>>;user=phone)
>  19:53:00.566    pjsua_app.c  Media for call 1 is active
>  19:53:00.566   pjsua_core.c  TX 869 bytes Response msg
> 200/INVITE/cseq=225308893 (tdta0x869c00) to UDP 80.179.0.4:5060:
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP 80.179.0.4:5060
> ;received=80.179.0.4;branch=z9hG4bKgqo3mo00d0b10koup7c0.1
> Call-ID: SD1m0gd01-cbf46a742831cc7b6fa4564187179755-06al420
> From: "a 1" <sip:1867@xxxxxxxxxxx <sip%3A1867 at 072.012.net> <
> sip%3A1867 at 072.012.net <sip%253A1867 at 072.012.net>>
> ;user=phone>;tag=SD1m0gd01-1080909488-1267465970104-
> To: "a 1" <sip:722511874 at 072.012.net <sip%3A722511874 at 072.012.net> <
> sip%3A722511874 at 072.012.net <sip%253A722511874 at 072.012.net>>
> >;tag=xbC9.pmCU9.-vEm7FhtxB25YcK.RmCye
> CSeq: 225308893 INVITE
> Contact: <sip:722511874 at 192.168.1.59:5060>
> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER,
> MESSAGE, OPTIONS
> Supported: replaces, 100rel, timer, norefersub
> Content-Type: application/sdp
> Content-Length:   274
>
> v=0
> o=- 3476454779 3476454780 IN IP4 192.168.1.59
> s=pjmedia
> c=IN IP4 192.168.1.59
> t=0 0
> a=X-nat:0
> m=audio 4002 RTP/AVP 18 101
> a=rtcp:4003 IN IP4 192.168.1.59
> a=rtpmap:18 G729/8000
> a=fmtp:18 annexb=no
> a=sendrecv
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
>
> --end msg--
>  19:53:00.569    pjsua_app.c  Call 1 state changed to CONNECTING
>  19:53:01.096   pjsua_core.c  TX 869 bytes Response msg
> 200/INVITE/cseq=225308893 (tdta0x869c00) to UDP 80.179.0.4:5060:
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP 80.179.0.4:5060
> ;received=80.179.0.4;branch=z9hG4bKgqo3mo00d0b10koup7c0.1
> Call-ID: SD1m0gd01-cbf46a742831cc7b6fa4564187179755-06al420
> From: "a 1" <sip:1867@xxxxxxxxxxx <sip%3A1867 at 072.012.net> <
> sip%3A1867 at 072.012.net <sip%253A1867 at 072.012.net>>
> ;user=phone>;tag=SD1m0gd01-1080909488-1267465970104-
> To: "a 1" <sip:722511874 at 072.012.net <sip%3A722511874 at 072.012.net> <
> sip%3A722511874 at 072.012.net <sip%253A722511874 at 072.012.net>>
> >;tag=xbC9.pmCU9.-vEm7FhtxB25YcK.RmCye
> CSeq: 225308893 INVITE
> Contact: <sip:722511874 at 192.168.1.59:5060>
> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER,
> MESSAGE, OPTIONS
> Supported: replaces, 100rel, timer, norefersub
> Content-Type: application/sdp
> Content-Length:   274
>
> v=0
> o=- 3476454779 3476454780 IN IP4 192.168.1.59
> s=pjmedia
> c=IN IP4 192.168.1.59
> t=0 0
> a=X-nat:0
> m=audio 4002 RTP/AVP 18 101
> a=rtcp:4003 IN IP4 192.168.1.59
> a=rtpmap:18 G729/8000
> a=fmtp:18 annexb=no
> a=sendrecv
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
>
> --end msg--
>  19:53:02.111   pjsua_core.c  TX 869 bytes Response msg
> 200/INVITE/cseq=225308893 (tdta0x869c00) to UDP 80.179.0.4:5060:
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP 80.179.0.4:5060
> ;received=80.179.0.4;branch=z9hG4bKgqo3mo00d0b10koup7c0.1
> Call-ID: SD1m0gd01-cbf46a742831cc7b6fa4564187179755-06al420
> From: "a 1" <sip:1867@xxxxxxxxxxx <sip%3A1867 at 072.012.net> <
> sip%3A1867 at 072.012.net <sip%253A1867 at 072.012.net>>
> ;user=phone>;tag=SD1m0gd01-1080909488-1267465970104-
> To: "a 1" <sip:722511874 at 072.012.net <sip%3A722511874 at 072.012.net> <
> sip%3A722511874 at 072.012.net <sip%253A722511874 at 072.012.net>>
> >;tag=xbC9.pmCU9.-vEm7FhtxB25YcK.RmCye
> CSeq: 225308893 INVITE
> Contact: <sip:722511874 at 192.168.1.59:5060>
> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER,
> MESSAGE, OPTIONS
> Supported: replaces, 100rel, timer, norefersub
> Content-Type: application/sdp
> Content-Length:   274
>
> v=0
> o=- 3476454779 3476454780 IN IP4 192.168.1.59
> s=pjmedia
> c=IN IP4 192.168.1.59
> t=0 0
> a=X-nat:0
> m=audio 4002 RTP/AVP 18 101
> a=rtcp:4003 IN IP4 192.168.1.59
> a=rtpmap:18 G729/8000
> a=fmtp:18 annexb=no
> a=sendrecv
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
>
> --end msg--
>  19:53:02.211   pjsua_core.c  RX 450 bytes Request msg ACK/cseq=225308893
> (rdata0x84d064) from UDP 80.179.0.4:5060:
> ACK sip:722511874 at 192.168.1.59:5060 SIP/2.0
> Via: SIP/2.0/UDP 80.179.0.4:5060;branch=z9hG4bK7d5nfa1060s0nmg3r3k0.1
> From: "a 1" <sip:1867@xxxxxxxxxxx <sip%3A1867 at 072.012.net> <
> sip%3A1867 at 072.012.net <sip%253A1867 at 072.012.net>>
> ;user=phone>;tag=SD1m0gd01-1080909488-1267465970104-
> To: "a 1" <sip:722511874 at 072.012.net <sip%3A722511874 at 072.012.net> <
> sip%3A722511874 at 072.012.net <sip%253A722511874 at 072.012.net>>
> >;tag=xbC9.pmCU9.-vEm7FhtxB25YcK.RmCye
> Call-ID: SD1m0gd01-cbf46a742831cc7b6fa4564187179755-06al420
> CSeq: 225308893 ACK
> Contact: <sip:1867 at 80.179.0.4:5060;transport=udp>
> Max-Forwards: 4
> Content-Length: 0
>
>
> --end msg--
>  19:53:02.214    pjsua_app.c  Call 1 state changed to CONFIRMED
>
>
> Regards,
> Maya
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20100304/617dd602/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
> End of pjsip Digest, Vol 31, Issue 4
> ************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20100304/9ba64e7e/attachment-0001.html>


[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux