Subject: [Sip] Re: Questions on draft-ietf-sip-outbound-05

From: Rohan Mahy <[email-masked]>
Date: Tue, 31 Oct 2006 19:05:20 -0800

Hi,

Often comments or questions are sent to the relevant WG mailing list 
([email-masked] in this case), but questions to the authors is fine.  I'm 
cc:ing the list so that others can see the answers to your questions. 
Answers inline.

On Oct 31, 2006, at 5:06, Vavilapalli Srikanth-A19563 wrote:
> Hi Jennings and Mahy
>  
> Not sure where to post my questions on this draft, hence mailing you 
> directly. Please redirect me if this is not the way to put the 
> questions.
>  1. Can I send multiple REGISTER messages with different AOR and same 
> +sip.instance ID and reg-id on a single network flow? I have not seen 
> any text in the draft preventing me from doing this, but just wanted 
> to get clarified. I mean I have multiple SIP applications running on 
> single device, so all applications will have same contact and have 
> single TCP connection from the device to OB proxy.

That should be fine.

>  2. Page 13, Section 4.2: Why is this draft mandating to have sets 
> with atleast two outbound proxy URI? In a simple SIP network 
> deployment scenario, where the "avalanche restart problem" is not an 
> issue, Can't we have the set with single outbound proxy URI?

The draft mandates that UAs can handle at least two URIs.  This is to 
insure interoperability between UAs and several kinds of networks.  
Some of these will need avalanche restart protection.

> 3. Page 13, Section 4.1: Can you give me an example of two URNs which 
> are functionally equivalent but lexigraphically different? When would 
> clients send such URNs in multiple registrations, where they are 
> functionally equal but not lexically? I assume UAs always send same 
> URN as +sip.instance value.

Take two UUID URNs, one that uses uppercase hex digits and the other 
that uses lowercase hex digits.  In practice this will never happen as 
long as the UA always sends the same string as the instance-id.

>  4. Page 15, Section 4.4: "For UDP, the upper bound of 29 seconds was 
> selected so that multiple STUN packets could be sent before 30 seconds 
> based on information that many NATs have UDP timeouts as low as 30 
> seconds" -  Can you please elaborate on this statement? Why/when would 
> UA send multiple STUN packets before 30 seconds?

STUN retransmissions will insure that if the first STUN query fails at 
29 seconds, several of STUN's normal retransmissions will happen before 
30 seconds.

> 5. Page 24, Section 8: "Unvalidated TCP or TLS over TCP flows, the 
> connection over which STUN requests were sent MUST be closed" -  Can't 
> UA fall back to some other keep-alive mechanism (some CRLF 
> messages) if the target is not validated for STUN support on a newly 
> established TCP flow?

No, because sending the STUN message over TCP will desynchronize the 
TCP framing if the UA can't handle STUN on the same stream.  You'll 
have to open a new connection, but can then do CRLF or TCP keepalives 
on the new connection.

> Why would the STUN failure trigger TCP connection closure?
> 	• 	If STUN support explicitly indicated
> 	◦ 	Validate the STUN support using explicit probe
> 	◦ 	If STUN support is validated
> 	▪ 	Mark the STUN support on that flow is validated
> 	◦ 	Else /* Explicit probing failed */
> 	▪ 	Fallback to some other keep alive mechanism like CRLF instead of 
> closing the TCP connection
> 	• 	Else /* No STUN support indicated */
> 	◦ 	Use some other mechanism to keep alive the hole (Ex. send a CRLF 
> packet)
>  
> 6. Page 26, Section 9: In the given example, UAC first sends the 
> request to primary and on receiving ICMP error it tries with 
> secondary. That means we expect the calling UAs (callers) to be 
> compliant with this draft or is this mechanism supported in RFC 3261 
> itself?

I'm not sure I know what you mean.  There is a lot of behavior 
described in RFC 3263 (which RFC 3261 says each implementation MUST 
implement).  Failover based on SRV records is in RFC 3263.  Trying to 
setup registrations with a primary and secondary because each is in the 
outbound-proxy-set is new in outbound.

thanks,
-rohan

> Appreciate your help in this regard.
>  
> Thanks&Regards
> Srikanth

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