> -----Ursprüngliche Nachricht-----
> Von: "Timo Bruhn" <[EMAIL PROTECTED]>
> Gesendet: 01.04.08 12:17:32
> An: sofia-sip-devel@lists.sourceforge.net
> Betreff: Re: [Sofia-sip-devel] Problems with bad contact address
>
> >2008/4/1, Timo Bruhn <[EMAIL PROTECTED]>:
> >> 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:[EMAIL PROTECTED]: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:[EMAIL PROTECTED]: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:[EMAIL PROTECTED]: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:[EMAIL PROTECTED]>;tag=rtX1K4vU8F6NN
To: <sips:[EMAIL PROTECTED]>
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:[EMAIL PROTECTED]>;tag=rtX1K4vU8F6NN
To: <sips:[EMAIL PROTECTED]>;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:[EMAIL PROTECTED]:1097;transport=tls SIP/2.0
Via: SIP/2.0/TLS 192.168.17.24;branch=z9hG4bKB08818HjKcX0B
Max-Forwards: 70
From: <sips:[EMAIL PROTECTED]:5060;transport=tls>;tag=HpNK3UUg1pX0K
To: <sips:[EMAIL PROTECTED]: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:[EMAIL PROTECTED]:5060;transport=tls>;tag=HpNK3UUg1pX0K
To: <sips:[EMAIL PROTECTED]: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:[EMAIL PROTECTED]:5060;transport=tls>;tag=HpNK3UUg1pX0K
To: <sips:[EMAIL PROTECTED]: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:[EMAIL PROTECTED]:5060;transport=tls>;tag=HpNK3UUg1pX0K
To: <sips:[EMAIL PROTECTED]: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:[EMAIL PROTECTED]:5060;transport=tls>;tag=HpNK3UUg1pX0K
To: <sips:[EMAIL PROTECTED]: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:[EMAIL PROTECTED]:5060;transport=tls>;tag=HpNK3UUg1pX0K
To: <sips:[EMAIL PROTECTED]: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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
