Problems with bad contact address

Hello all,

at the moment I seem to have a problem similiar to that one described in a mail by
Michael Jerris some months ago.

>>[Sofia-sip-devel] bad contact adress.
>>
>>Michael Jerris
>>Wed, 10 Oct 2007 09:48:25 -0700

>>We have a problem where we send an invite to a client behind nat, that is
>>registered to us.  When they respond 100, the contact address is incorrectly
>>an internal 192.168 adress, and all our responses after that (prack for
>>example) try to go to the unroutable 192 address.  Are there tags that can
>>turn on detection of this or change this behavior?

>>Mike

In my scenario a client (with sofialib) registers with to my application (nua-api, sofia 1.12.8) over tls.
Because of the already know problem the client does not write the used tcp port to
the contact header, but the port specified with NUTAG_SIPS_URL in nua_create().

If I want to call this client through the open tcp/tls-connection know, I dont't send the request to the port
used 
I received in contact-header, but to the port really used by the client (I save the port when i receive the register
from the client and put it into the to-header in my outgoing invite). 

This works and the tcp/tls-connection opened by client for the register request is re-used for the invite.
But when I the send an ACK or BYE to the client, the stack always uses the port the client

Re: Problems with bad contact address

2008/4/1, Timo Bruhn <voip_voip@...>:
>  In my scenario a client (with sofialib) registers with to my application (nua-api, sofia 1.12.8) over tls.
>  Because of the already know problem the client does not write the used tcp port to
>  the contact header, but the port specified with NUTAG_SIPS_URL in nua_create().
>
>  If I want to call this client through the open tcp/tls-connection know, I dont't send the request to the
port used
>  I received in contact-header, but to the port really used by the client (I save the port when i receive the register
>  from the client and put it into the to-header in my outgoing invite).
>
>  This works and the tcp/tls-connection opened by client for the register request is re-used for the invite.
>  But when I the send an ACK or BYE to the client, the stack always uses the port the client
>  specified in contact-header in register.

So you have two UA's using Sofia-SIP, one (A) registers from NATted
network and another one (B) calls outside through the registrar/proxy.
When B sends an INVITE to A, the proxy uses correctly the connection
incoming from UA A for outbound INVITE. However, the ACK and BYE
requests sent by UA B within dialog are routed directly to the Contact
address given by A?

>  Is there any known solution to this problem? Can I specifiy the destination port when calling
>  nua_bye() or nua_ack()?

Basically, this is outbound problem: the proxy should add a
Record-Route header to the INVITE it sends to A. (A copies
Record-Route to the response, and B uses the Record-Route URI when
sending the ACK and BYE.) The proxy should also map the incoming
ACK/BYE to the A's connection somehow (it can use methods described in
draft-ietf-sip-outbound, for instance).

Re: Problems with bad contact address

>2008/4/1, Timo Bruhn <voip_voip@...>:
>>  In my scenario a client (with sofialib) registers with to my application (nua-api, sofia 1.12.8) over tls.>
>>  Because of the already know problem the client does not write the used tcp port to
>>  the contact header, but the port specified with NUTAG_SIPS_URL in nua_create().
>>
>>  If I want to call this client through the open tcp/tls-connection know, I dont't send the request to the
port used
>>  I received in contact-header, but to the port really used by the client (I save the port when i receive the register
>>  from the client and put it into the to-header in my outgoing invite).
>>
>>  This works and the tcp/tls-connection opened by client for the register request is re-used for the invite.
>>  But when I the send an ACK or BYE to the client, the stack always uses the port the client
>>  specified in contact-header in register.

>So you have two UA's using Sofia-SIP, one (A) registers from NATted
>network and another one (B) calls outside through the registrar/proxy.
>When B sends an INVITE to A, the proxy uses correctly the connection
>incoming from UA A for outbound INVITE. However, the ACK and BYE
>requests sent by UA B within dialog are routed directly to the Contact
>address given by A?

>>  Is there any known solution to this problem? Can I specifiy the destination port when calling
>>  nua_bye() or nua_ack()?

>Basically, this is outbound problem: the proxy should add a
>Record-Route header to the INVITE it sends to A. (A copies
>Record-Route to the response, and B uses the Record-Route URI when
>sending the ACK and BYE.) The proxy should also map the incoming
>ACK/BYE to the A's connection somehow (it can use methods described in
>draft-ietf-sip-outbound, for instance).

Re: Allow-Events Header Not Appearing in Outbound Requests

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

_______________________________________________
Sofia-sip-devel mailing list
Sofia-sip-devel@...
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

sofia-sip changes (2008-04-01)

This posting was generated automatically from darcs repo
<http://sofia-sip.org/repos/sofia-sip>.

Tue Apr  1 13:49:10 EEST 2008  Pekka.Pessi@...
  * nua_stack.c: include Allow-Events in most messages initiating dialog

  The Allow-Events header is now included with NOTIFY, PUBLISH, REGISTER, and
  initial INVITE, SUBSCRIBE, REFER, and OPTIONS, and also responses to
  SUBSCRIBE, REFER, OPTIONS, and PUBLISH as well as responses to initial
  INVITE and NOTIFY.

  Thanks to Jerry Richards for pointing out the problem.

    M ./libsofia-sip-ua/nua/nua_stack.c -1 +5

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Re: Assertion failed

2008/3/29, Fabio Margarido <fabiomargarido@...>:
> The attached patch fixes the behavior of --enable-ndebug. No thoughts
>  on the assertion?

Thanks for the patch. Please note that configure is generated from
configure.ac and assorted m4 files in m4 directory, which should be
fixed instead of configure.

I think your assertion problem has been fixed in the darcs version, I
think it was caused by a glare problem (re-INVITE sent by both
end-points simultaneously) that was not detected correctly. In the
current code, glare detection has been fixed and the assertion
removed.

--Pekka

>  On Wed, Mar 26, 2008 at 12:32 PM, Fabio Margarido
>  <fabiomargarido@...> wrote:
>  > Hi there,
>  >
>  >  I've hit this today:
>  >
>  >  nua_session.c:1974: nua_invite_server_preprocess: Assertion
>  >  'ss->ss_state >= nua_callstate_ready || ss->ss_state ==
>  >  nua_call_state_init' failed.
>  >
>  >  I can't tell what has happening at the moment to trigger this error.
>  >  Any thoughts?
>  >  I've already asked this before but never got any answer: this is with
>  >  a library compiled with --enable-ndebug. Is this flag working
>  >  correctly?
>  >  Thanks in advance.
>  >
>  >  Fabio
>  >
>
> -------------------------------------------------------------------------
>  Check out the new SourceForge.net Marketplace.
>  It's the best place to buy or sell services for
>  just about anything Open Source.
>  http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
>  Sofia-sip-devel mailing list
>  Sofia-sip-devel@...
>  https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
>
>
>

--

-- 
Pekka.Pessi mail at nokia.com

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

[ sofia-sip-Bugs-1930055 ] Unregister when a new public binding is detected

Bugs item #1930055, was opened at 2008-03-31 13:47
Message generated for change (Comment added) made by mzabaluev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1930055&group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
>Priority: 1
Private: No
Submitted By: Mikhail Zabaluev (mzabaluev)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unregister when a new public binding is detected

Initial Comment:
When outbound detects a new address binding, any successful registration by the same NUA handle should be
explicitly unregistered. This may be needed in two cases:
1) weird configurations with NAT and no authentication;
2) when the binding changes on a NAT middle box.

See also the discussion on a maemo bug:
https://bugs.maemo.org/show_bug.cgi?id=3056

----------------------------------------------------------------------

>Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2008-04-02 11:59

Message:
Logged In: YES 
user_id=313104
Originator: YES

Maybe it's not a good idea to unregister _before_ the contact is updated.
But it could be done afterwards (after the whole update transaction, or
perhaps just firing an un-REGISTER request right after the REGISTER with a
contact update is sent?).
OTOH, it can bring more issues with saner proxies, than it solves with a
few not-so-sane examples.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=756076&aid=1930055&group_id=143636

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Re: Assertion failed

On Tue, Apr 1, 2008 at 6:50 PM, Pekka Pessi <ppessi@...> wrote:

> Thanks for the patch. Please note that configure is generated from
> configure.ac and assorted m4 files in m4 directory, which should be
> fixed instead of configure.
>

Oops... zero knowledge in autotools causes this, sorry.. :)
Hopefully this is the right one:

--- sac-general.m4.orig 2008-01-17 12:45:31.000000000 -0200
+++ sac-general.m4      2008-04-02 08:32:20.000000000 -0300
 <at>  <at>  -325,7 +325,7  <at>  <at> 
 AC_ARG_ENABLE(ndebug,
 [  --enable-ndebug         compile with NDEBUG [[disabled]]],
  , enable_ndebug=no)
-AM_CONDITIONAL(NDEBUG, test x$enable_ndebug = yes)
+AM_CONDITIONAL(NDEBUG, test x$enable_ndebug = xyes)
 ])

 dnl ======================================================================
 <at>  <at>  -339,7 +339,7  <at>  <at> 
 if test $enable_expensive_checks != no; then
 AC_SUBST([TESTS_ENVIRONMENT], [EXPENSIVE_CHECKS=1])
 fi
-AM_CONDITIONAL(EXPENSIVE_CHECKS, test x$enable_expensive_checks != no)
+AM_CONDITIONAL(EXPENSIVE_CHECKS, test x$enable_expensive_checks != xno)
 ])

>
> I think your assertion problem has been fixed in the darcs version, I
> think it was caused by a glare problem (re-INVITE sent by both
> end-points simultaneously) that was not detected correctly. In the
> current code, glare detection has been fixed and the assertion
> removed.

Great. As soon as I can, I'll give it a try.
Thanks a lot.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Re: Problems with bad contact address

> -----Ursprüngliche Nachricht-----
> Von: "Timo Bruhn" <voip_voip@...>
> Gesendet: 01.04.08 12:17:32
> An: sofia-sip-devel@...
> Betreff: Re: [Sofia-sip-devel] Problems with bad contact address

> 
> >2008/4/1, Timo Bruhn <voip_voip@...>:
> >>  In my scenario a client (with sofialib) registers with to my application (nua-api, sofia 1.12.8) over tls.>
> >>  Because of the already know problem the client does not write the used tcp port to
> >>  the contact header, but the port specified with NUTAG_SIPS_URL in nua_create().
> >>
> >>  If I want to call this client through the open tcp/tls-connection know, I dont't send the request to the
port used
> >>  I received in contact-header, but to the port really used by the client (I save the port when i receive the register
> >>  from the client and put it into the to-header in my outgoing invite).
> >>
> >>  This works and the tcp/tls-connection opened by client for the register request is re-used for the invite.
> >>  But when I the send an ACK or BYE to the client, the stack always uses the port the client
> >>  specified in contact-header in register.
> 
> >So you have two UA's using Sofia-SIP, one (A) registers from NATted
> >network and another one (B) calls outside through the registrar/proxy.
> >When B sends an INVITE to A, the proxy uses correctly the connection
> >incoming from UA A for outbound INVITE. However, the ACK and BYE
> >requests sent by UA B within dialog are routed directly to the Contact
> >address given by A?
> 
> >>  Is there any known solution to this problem? Can I specifiy the destination port when calling
> >>  nua_bye() or nua_ack()?
> 
> >Basically, this is outbound problem: the proxy should add a
> >Record-Route header to the INVITE it sends to A. (A copies
> >Record-Route to the response, and B uses the Record-Route URI when
> >sending the ACK and BYE.) The proxy should also map the incoming
> >ACK/BYE to the A's connection somehow (it can use methods described in
> >draft-ietf-sip-outbound, for instance).
> 
> Thanks for our quick answer.
> 
> Unfortunately I haven't described my scenario clear enough.
> 
> In fact I am using nua-api to implement a proxy/registrar, just like freeswitch guys do.
> So I am the proxy and call an UA previously registered to me over tcp/tls. This
> UA is not behind NAT, it is in the same subnet as the proxy is. Very simple
> configuration.
> 
> The UA (sofia 1.12.6) registers with the proxy(me, sofia 1.12.8) with contact address like this:
> "sips:username@...:5060".
> 
> But in fact it uses a different tcp port for the register. I think Stefan Leuenberger
> reported this to the list some months ago.
> 
> Now I save the tcp port used for the register request by the UA to overcome the problem.
> Lets say its port 1234.
> 
> When the proxy wants to call the UA over tls it re-uses the connection (just because
> the UA does not have certificates).
> 
> Therefore i use a to-header like this:
> "sips:username@...:1234;transport=tls".
> 
> This works. The INVITE is sent through the previously opened connection. After the
> UA responded with 200 OK, I send the ACK.  Unfortunately this ACK is sent to
> 192.168.0.2:5060 through a new tcp connection.  Same Problem with BYE.
> 
> 

Hello,

again about this problem with the wrong contact. I added a small trace showing the 
problem. As you can see the trace was made with TPTAG_DUMP.

The UA 1213 registers at the proxy (ip 192.168.17.24) over tls. 

Afterwards the proxy calls the UA. In to header
To: <sips:1213@...:1097;transport=tls>
the real remote port is used instead of the one in register contact.

The last message in the trace is the ACK from proxy to UA. This one
goes to the port from register contact which is of course not wanted here.
(Same with all other outgoing requests...)

To fix this problem I could try to find a workaround to send all requests of
one call to the port in to header and not to the one from contact, but I think
the real problem here is, that the tcp port does not make it into the contact
header in register request. Am I right here?

If a bind is added in tport for connection oriented ports (to bind the local socket
with the port specified in contact header) which sideeffects would that have?

Would it be easier to let the outbound logic detect that contact port and rport
are different and retrigger the register with correct port in contact?

Timo

_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

recv 470 bytes from tls/[192.168.17.62]:1097 at 17:24:50.847382:
REGISTER sips:192.168.17.24 SIP/2.0
Via: SIP/2.0/TLS 192.168.17.62:5060;branch=z9hG4bKrr8264j1jtrBm
Max-Forwards: 70
From: <sips:1213@...>;tag=rtX1K4vU8F6NN
To: <sips:1213@...>
Call-ID: a50bfc9b-3a93-1222-a09d-cb9b74343e59
CSeq: 101445746 REGISTER
Contact: <sips:192.168.17.62:5060>
Expires: 60
User-Agent: sofia-sip/1.12.6
Allow: INVITE, ACK, BYE, CANCEL, PRACK, NOTIFY, REFER
Supported: timer, 100rel, path
Content-Length: 0

sent 473 bytes to tls/[192.168.17.62]:1097 at 17:24:50.886094:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.168.17.62:5060;branch=z9hG4bKS11U8Z34F3eyF;rport=1097
From: <sips:1213@...>;tag=rtX1K4vU8F6NN
To: <sips:1213@...>;tag=c9pQtm7yFae3S
Call-ID: a50bfc9b-3a93-1222-a09d-cb9b74343e59
CSeq: 101445747 REGISTER
Contact: <sips:192.168.17.62:5060>
Expires: 60
User-Agent: sofia-sip/1.12.8
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, REGISTER
Supported: timer, 100rel
Content-Length: 0


sent 541 bytes to tls/[192.168.17.62]:1097 at 17:25:01.648633:
INVITE sips:1213@...:1097;transport=tls SIP/2.0
Via: SIP/2.0/TLS 192.168.17.24;branch=z9hG4bKB08818HjKcX0B
Max-Forwards: 70
From: <sips:1214@...:5060;transport=tls>;tag=HpNK3UUg1pX0K
To: <sips:1213@...:1097;transport=tls>
Call-ID: dfb6555d-d155-1223-df97-00095200a0c2
CSeq: 123807542 INVITE
Contact: <sip:192.168.17.24>
User-Agent: sofia-sip/1.12.8
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, REGISTER
Supported: timer, 100rel
Min-SE: 120
Content-Length: 0


recv 352 bytes from tls/[192.168.17.62]:1097 at 17:25:01.669950:
SIP/2.0 100 Trying
Via: SIP/2.0/TLS 192.168.17.24;branch=z9hG4bKB08818HjKcX0B;rport=5061
From: <sips:1214@...:5060;transport=tls>;tag=HpNK3UUg1pX0K
To: <sips:1213@...:1097;transport=tls>
Call-ID: dfb6555d-d155-1223-df97-00095200a0c2
CSeq: 123807542 INVITE
User-Agent: sofia-sip/1.12.6
Content-Length: 0


recv 494 bytes from tls/[192.168.17.62]:1097 at 17:25:01.808660:
SIP/2.0 100 Trying
Via: SIP/2.0/TLS 192.168.17.24;branch=z9hG4bKB08818HjKcX0B;rport=5061
From: <sips:1214@...:5060;transport=tls>;tag=HpNK3UUg1pX0K
To: <sips:1213@...:1097;transport=tls>
Call-ID: dfb6555d-d155-1223-df97-00095200a0c2
CSeq: 123807542 INVITE
Contact: <sips:192.168.17.62:5060>
User-Agent: sofia-sip/1.12.6
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, PRACK, NOTIFY, REFER
Supported: timer, 100rel
Content-Length: 0


recv 488 bytes from tls/[192.168.17.62]:1097 at 17:25:01.816028:
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS 192.168.17.24;branch=z9hG4bKB08818HjKcX0B;rport=5061
From: <sips:1214@...:5060;transport=tls>;tag=HpNK3UUg1pX0K
To: <sips:1213@...:1097;transport=tls>;tag=S3ptNZDZ5rv8g
Call-ID: dfb6555d-d155-1223-df97-00095200a0c2
CSeq: 123807542 INVITE
Contact: <sips:192.168.17.62:5060>
User-Agent: sofia-sip/1.12.6
Allow: INVITE, ACK, BYE, CANCEL, PRACK, NOTIFY, REFER
Supported: timer, 100rel
Content-Length: 0

recv 559 bytes from tls/[192.168.17.62]:1097 at 17:25:04.290665:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.168.17.24;branch=z9hG4bKB08818HjKcX0B;rport=5061
From: <sips:1214@...:5060;transport=tls>;tag=HpNK3UUg1pX0K
To: <sips:1213@...:1097;transport=tls>;tag=S3ptNZDZ5rv8g
Call-ID: dfb6555d-d155-1223-df97-00095200a0c2
CSeq: 123807542 INVITE
Contact: <sips:192.168.17.62:5060>
User-Agent: sofia-sip/1.12.6
Allow: INVITE, ACK, BYE, CANCEL, PRACK, NOTIFY, REFER
Supported: timer, 100rel
Min-SE: 400
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 353


sent 674 bytes to tls/[192.168.17.62]:5060 at 17:25:04.849344:
ACK sips:192.168.17.62:5060 SIP/2.0
Via: SIP/2.0/TLS 192.168.17.24;branch=z9hG4bKc911332NgNKKQ
Max-Forwards: 70
From: <sips:1214@...:5060;transport=tls>;tag=HpNK3UUg1pX0K
To: <sips:1213@...:1097;transport=tls>;tag=S3ptNZDZ5rv8g
Call-ID: dfb6555d-d155-1223-df97-00095200a0c2
CSeq: 123807542 ACK
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 258



-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

_______________________________________________
Sofia-sip-devel mailing list
Sofia-sip-devel@...
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

FW: Sofia SIP sending incorrect SDP on resuming the call

Hi,

the attached message was sent to the wrong list 
address.

-- 

From: Hi, the attached message was sent to the wrong list address. -- <Subbu_Rajendran@...>
Subject: Sofia SIP sending incorrect SDP on resuming the call
Date: 2008-04-02 05:53:51 GMT

Hi,

Sofia SIP sending incorrect offer SDP in 200 OK when the network resumes the call after putting it on hold.
The offer SDP contains "a=recvonly" attribute. Also it does not advertise the complete list of supported
codecs, instead it re-uses the initially negotiated codec.  Network uses delayed media scenario on
resuming the call. The offer send by Sofia SIP in 200 OK looks like the copy of the answer SDP sent in the
previous INVITE transaction made to put on hold.

How can I get the Sofia SIP to make a fresh offer in the re-invite scenario? At least have the offer advertise
"a=sendrecv" instead of "a=recvonly".

Any help in this regard will be very useful.

The call flow is as shown below

Sofia                N/W

INVITE  -->

            <--        100/180/200

ACK     -->

<== 2-Way Voice ==>

            <--        INVITE   (SDP for On hold)

200       -->

            <--        ACK

<== No Voice ==>

            <--        INVITE   (w/o SDP)

200       -->

            <--        ACK (w/ SDP)

The SIP trace is given below:

send 753 bytes to udp/[10.20.30.18]:5060 at 00:31:37.638345:

   ------------------------------------------------------------------------

   INVITE sip:2005@... SIP/2.0

   Via: SIP/2.0/UDP 10.20.30.36;rport;branch=z9hG4bKmDDQDN6rNt0XF

   Max-Forwards: 70

   From: inPhone <sip:2020@...>;tag=B9r0UgUe6Qv0a

   To: <sip:2005@...>

   Call-ID: 58e9947e-2160-1222-b681-31b428cd4c6e

   CSeq: 100060340 INVITE

   Contact: inPhone <sip:2020@...;user=phone>

   User-Agent: sofia-sip/1.12.1

   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER

   Supported: timer, 100rel

   Min-SE: 120

   Content-Type: application/sdp

   Content-Disposition: session

   Content-Length: 152

   v=0

   o=- 3081347780568533424 15046803205496196825 IN IP4 10.20.30.37

   s=-

   t=0 0

   m=audio 10000 RTP/AVP 0 8 4 4 18 99 100 98 101

   c=IN IP4 10.20.30.36

   ------------------------------------------------------------------------

recv 331 bytes from udp/[10.20.30.18]:5060 at 00:31:38.307247:

   ------------------------------------------------------------------------

   SIP/2.0 100 Trying

   Via: SIP/2.0/UDP 10.20.30.36;rport;branch=z9hG4bKmDDQDN6rNt0XF

   From: inPhone <sip:2020@...>;tag=B9r0UgUe6Qv0a

   To: <sip:2005@...>

   Date: Mon, 31 Mar 2008 11:35:39 GMT

   Call-ID: 58e9947e-2160-1222-b681-31b428cd4c6e

   CSeq: 100060340 INVITE

   Allow-Events: presence

   Content-Length: 0

   ------------------------------------------------------------------------   

recv 595 bytes from udp/[10.20.30.18]:5060 at 00:31:38.311864:

   ------------------------------------------------------------------------

   SIP/2.0 180 Ringing

   Via: SIP/2.0/UDP 10.20.30.36;rport;branch=z9hG4bKmDDQDN6rNt0XF

   From: inPhone <sip:2020@...>;tag=B9r0UgUe6Qv0a

   To: <sip:2005@...>;tag=cfa850bf-a180-4e71-9b81-62d43df3a4f0-25310240

   Date: Mon, 31 Mar 2008 11:35:39 GMT

   Call-ID: 58e9947e-2160-1222-b681-31b428cd4c6e

   CSeq: 100060340 INVITE

   Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, PUBLISH

   Allow-Events: presence

   Remote-Party-ID: <sip:2005@...>;party=called;screen=yes;privacy=off

   Contact: <sip:2005@...:5060>

   Content-Length: 0

   ------------------------------------------------------------------------

recv 854 bytes from udp/[10.20.30.18]:5060 at 00:31:39.480334:

   ------------------------------------------------------------------------

   SIP/2.0 200 OK

   Via: SIP/2.0/UDP 10.20.30.36;rport;branch=z9hG4bKmDDQDN6rNt0XF

   From: inPhone <sip:2020@...>;tag=B9r0UgUe6Qv0a

   To: <sip:2005@...>;tag=cfa850bf-a180-4e71-9b81-62d43df3a4f0-25310240

   Date: Mon, 31 Mar 2008 11:35:39 GMT

   Call-ID: 58e9947e-2160-1222-b681-31b428cd4c6e

   CSeq: 100060340 INVITE

   Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, PUBLISH

   Allow-Events: presence

   Remote-Party-ID: <sip:2005@...>;party=called;screen=yes;privacy=off

   Contact: <sip:2005@...:5060>

   Supported: replaces

   Session-Expires:  1800;refresher=uas

   Require:  timer

   Content-Type: application/sdp

   Content-Length: 155

   v=0

   o=SIP 2000 1 IN IP4 10.20.30.18

   s=SIP Call

   c=IN IP4 10.20.30.130

   t=0 0

   m=audio 17656 RTP/AVP 0

   a=rtpmap:0 PCMU/8000

   a=ptime:20

   ------------------------------------------------------------------------

send 354 bytes to udp/[10.20.30.18]:5060 at 00:31:39.494284:

   ------------------------------------------------------------------------

   ACK sip:2005@...:5060 SIP/2.0

   Via: SIP/2.0/UDP 10.20.30.36;rport;branch=z9hG4bKDK3HF3yZj3SyH

   Max-Forwards: 70

   From: inPhone <sip:2020@...>;tag=B9r0UgUe6Qv0a

   To: <sip:2005@...>;tag=cfa850bf-a180-4e71-9b81-62d43df3a4f0-25310240

   Call-ID: 58e9947e-2160-1222-b681-31b428cd4c6e

   CSeq: 100060340 ACK

   Content-Length: 0

   ------------------------------------------------------------------------

recv 1000 bytes from udp/[10.20.30.18]:5060 at 00:31:46.402500:

   ------------------------------------------------------------------------

   INVITE sip:2020@...:5060;user=phone SIP/2.0

   Via: SIP/2.0/UDP 10.20.30.18:5060;branch=z9hG4bKdb5eaf096d

   Remote-Party-ID: <sip:2005@...>;party=calling;screen=yes;privacy=off

   From: <sip:2005@...>;tag=cfa850bf-a180-4e71-9b81-62d43df3a4f0-25310240

   To: inPhone <sip:2020@...>;tag=B9r0UgUe6Qv0a

   Date: Mon, 31 Mar 2008 11:35:48 GMT

   Call-ID: 58e9947e-2160-1222-b681-31b428cd4c6e

   Supported: timer,replaces

   Min-SE:  1800

   Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, PUBLISH

   CSeq: 101 INVITE

   Max-Forwards: 70

   Contact: <sip:2005@...:5060>

   Expires: 180

   Allow-Events: presence

   Session-Expires:  1800;refresher=uac

   Content-Type: application/sdp

   Content-Length: 162

   v=0

   o=SIP 2000 2 IN IP4 10.20.30.18

   s=SIP Call

   c=IN IP4 0.0.0.0

   t=0 0

   m=audio 17656 RTP/AVP 0

   a=rtpmap:0 PCMU/8000

   a=ptime:20

   a=inactive

   ------------------------------------------------------------------------

send 822 bytes to udp/[10.20.30.18]:5060 at 00:31:46.419202:

   ------------------------------------------------------------------------

   SIP/2.0 200 OK

   Via: SIP/2.0/UDP 10.20.30.18:5060;branch=z9hG4bKdb5eaf096d

   From: <sip:2005@...>;tag=cfa850bf-a180-4e71-9b81-62d43df3a4f0-25310240

   To: inPhone <sip:2020@...>;tag=B9r0UgUe6Qv0a

   Call-ID: 58e9947e-2160-1222-b681-31b428cd4c6e

   CSeq: 101 INVITE

   Contact: inPhone <sip:2020@...;user=phone>

   User-Agent: sofia-sip/1.12.1

   Accept: application/sdp

   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER

   Require: timer

   Supported: timer, 100rel

   Session-Expires: 1800;refresher=uac

   Min-SE: 1800

   Content-Type: application/sdp

   Content-Disposition: session

   Content-Length: 141

   v=0

   o=- 3081347780568533424 15046803205496196825 IN IP4 10.20.30.37

   s=-

   t=0 0

   m=audio 10000 RTP/AVP 0

   c=IN IP4 10.20.30.36

   a=recvonly

   ------------------------------------------------------------------------

recv 416 bytes from udp/[10.20.30.18]:5060 at 00:31:47.095094:

   ------------------------------------------------------------------------

   ACK sip:2020@...:5060;user=phone SIP/2.0

   Via: SIP/2.0/UDP 10.20.30.18:5060;branch=z9hG4bKdc608b08a0

   From: <sip:2005@...>;tag=cfa850bf-a180-4e71-9b81-62d43df3a4f0-25310240

   To: inPhone <sip:2020@...>;tag=B9r0UgUe6Qv0a

   Date: Mon, 31 Mar 2008 11:35:48 GMT

   Call-ID: 58e9947e-2160-1222-b681-31b428cd4c6e

   Max-Forwards: 70

   CSeq: 101 ACK

   Allow-Events: presence

   Content-Length: 0

   ------------------------------------------------------------------------

recv 804 bytes from udp/[10.20.30.18]:5060 at 00:31:47.773223:

   ------------------------------------------------------------------------

   INVITE sip:2020@...:5060;user=phone SIP/2.0

   Via: SIP/2.0/UDP 10.20.30.18:5060;branch=z9hG4bKddd34486c

   Remote-Party-ID: <sip:2005@...>;party=calling;screen=yes;privacy=off

   From: <sip:2005@...>;tag=cfa850bf-a180-4e71-9b81-62d43df3a4f0-25310240

   To: inPhone <sip:2020@...>;tag=B9r0UgUe6Qv0a

   Date: Mon, 31 Mar 2008 11:35:48 GMT

   Call-ID: 58e9947e-2160-1222-b681-31b428cd4c6e

   Supported: timer,replaces

   Min-SE:  1800

   Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, PUBLISH

   CSeq: 102 INVITE

   Max-Forwards: 70

   Contact: <sip:2005@...:5060>

   Expires: 180

   Allow-Events: presence

   Session-Expires:  1800;refresher=uac

   Content-Length: 0

   ------------------------------------------------------------------------

send 821 bytes to udp/[10.20.30.18]:5060 at 00:31:48.449168:

   ------------------------------------------------------------------------

   SIP/2.0 200 OK

   Via: SIP/2.0/UDP 10.20.30.18:5060;branch=z9hG4bKddd34486c

   From: <sip:2005@...>;tag=cfa850bf-a180-4e71-9b81-62d43df3a4f0-25310240

   To: inPhone <sip:2020@...>;tag=B9r0UgUe6Qv0a

   Call-ID: 58e9947e-2160-1222-b681-31b428cd4c6e

   CSeq: 102 INVITE

   Contact: inPhone <sip:2020@...;user=phone>

   User-Agent: sofia-sip/1.12.1

   Accept: application/sdp

   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER

   Require: timer

   Supported: timer, 100rel

   Session-Expires: 1800;refresher=uac

   Min-SE: 1800

   Content-Type: application/sdp

   Content-Disposition: session

   Content-Length: 141

   v=0

   o=- 3081347780568533424 15046803205496196825 IN IP4 10.20.30.37

   s=-

   t=0 0

   m=audio 10000 RTP/AVP 0

   c=IN IP4 10.20.30.36

   a=recvonly

   ------------------------------------------------------------------------

recv 614 bytes from udp/[10.20.30.18]:5060 at 00:31:49.802088:

   ------------------------------------------------------------------------

   ACK sip:2020@...:5060;user=phone SIP/2.0

   Via: SIP/2.0/UDP 10.20.30.18:5060;branch=z9hG4bKde3ac27db9

   From: <sip:2005@...>;tag=cfa850bf-a180-4e71-9b81-62d43df3a4f0-25310240

   To: inPhone <sip:2020@...>;tag=B9r0UgUe6Qv0a

   Date: Mon, 31 Mar 2008 11:35:50 GMT

   Call-ID: 58e9947e-2160-1222-b681-31b428cd4c6e

   Max-Forwards: 70

   CSeq: 102 ACK

   Allow-Events: presence

   Content-Type: application/sdp

   Content-Length: 165

   v=0

   o=SIP 2000 3 IN IP4 10.20.30.18

   s=SIP Call

   c=IN IP4 10.20.30.18

   t=0 0

   m=audio 4000 RTP/AVP 0

   a=rtpmap:0 PCMU/8000

   a=ptime:20

   a=sendonly

   ------------------------------------------------------------------------

--

Subbu

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the
addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the
original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any
other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every
reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of
any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or
attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from
this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
	

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

_______________________________________________
Sofia-sip-devel mailing list
Sofia-sip-devel@...
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel