Subject: [Sipping] re: what happens if both SIP UAs want to be active

From: Jiri Kuthan <[email-masked]>
Date: Mon, 16 Jun 2003 21:05:21 +0200

[ok, I'm diverting from mmusic to sipping and re-asking the same question again.]

My today's problem is it is difficult to detect when signaling using comedia 
fails because of both UAs behind symmetric NATs trying to enter symmetric active 
mode. If entities in the signaling path (proxies, b2bua, whatsoever) know 
what happened, they can try other means of NAT traversal. The missing piece 
is that they don't know what happened -- there is no specific error code for 
this condition in SIP.

It's thus imho very desirable to introduce such an error code.

Comments?

-Jiri

At 07:07 PM 6/16/2003, David Yon wrote:
>The SIP gurus can chime in, but seems to me it would be in the same category as not being able to come to an agreement vis-a-vis which codec to use.
>
>At 12:25 PM 6/16/2003, Jiri Kuthan wrote:
>>[sorry, misthreaded -- I copy'n'pasted from archive since I was stripped
>> off the recepient list]
>>
>>What does it mean SIP-wise that negotiation fails?
>>
>>I mean it would be great to have a special code for this error which
>>allows SIP entities to recognized these conditions and act approprietly.
>>
>>-Jiri
>>
>>on Sun, 08 Jun 2003 17:31:12 -0400, David wrote:
>>> If they both want to be active, the negotiation fails.
>>
>>>> At 12:47 PM 6/7/2003, Jiri Kuthan wrote:
>>>> David,
>>>>
>>>> can you please explain me how SIP signaling proceeds if two UAs both
>>>> with to have direction=active, since they are behind symmetric NATs?
>>>>
>>>> Thanks,
>>>>
>>>> -jiri
>>
>>--
>>Jiri Kuthan            http://iptel.org/~jiri/
>
>--
>Jiri Kuthan            http://iptel.org/~jiri/ 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Yutaka Takeda" <[email-masked]>
Date: Fri, 20 Jun 2003 11:50:22 -0700

Hello Jiri,

I have been working on similar issue. Following I-D I posted might
interest you with regard to symmetric NAT traversal at both ends 
using STUN. It provides other aspects of applicability of STUN.
[1] http://www.ietf.org/internet-drafts/draft-takeda-symmetric-nat-traversal-00.txt

I agree that it is desirable to be able to tell what is happening in 
such cases.

My I-D[1] does not address any specific protocol, however, 
it proposes to exchange port allocation rule of NATs, which
will tell the other if it is a symmetric NAT or a cone NAT, 
between clients behind NATs so that both clients know what to do 
and if it is the case where both ends are behind symmetric NATs,
the clients can try another NAT solution, such as TURN, 
or try out the port prediction as mentioned in [2]. The latter one, 
however, may fall into the same situation (no sound).

The existing proposal that I know of to solve this connectivity
issue is ICE (If am correct).
[2] http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-ice-00.txt
I am still in process of reading it...

Yutaka

>Jiri Kuthan wrote:
> >The SIP gurus can chime in, but seems to me it would be in 
> the same category as not being able to come to an agreement 
> vis-a-vis which codec to use.
> >