Subject: Re: [Sip] Comments on draft-ietf-sip-outbound-07

From: Cullen Jennings <[email-masked]>
Date: Sun, 4 Mar 2007 10:19:00 -0800

On Jan 22, 2007, at 12:27 AM, Alfred E. Heggestad wrote:

> Comments on draft-ietf-sip-outbound-07
>
>
> > 3.5.  Keepalive Technique
> >
> >    For connection-less transports, a flow definition could change
> >    because a NAT device in the network path reboots and the  
> resulting
> >    public IP address or port mapping for the UA changes.  To detect
> >    this, requests are sent over the same flow that is being used  
> for the
> >          ^^^^^^^^^^^^^^^^^
>
> suggest renaming to "STUN Binding Requests are periodically sent ..."
uh - sort of fixed - the latest version has three types of keep alive  
so it is weirder

>
>
> > 4.1.  Instance ID Creation
> >
> >   Each UA MUST have an Instance Identifier URN that uniquely  
> identifies
> >
> >   ...
> >
> >   The UA SHOULD include a "sip.instance" media feature tag as a UA
> >
>
> Why should the UA have a URN if it cannot use it in the signaling ?
> Maybe change SHOULD to MUST ?

fixed - the only times you don't want to do this are privacy related

>
>
> > 4.4.  Detecting Flow Failure
> >
> >    The time between keepalive requests when using UDP-based  
> transports
> >    SHOULD be a random number between 24 and 29 seconds while for  
> TCP-
> >    based transports it SHOULD be a random number between 95 and 120
> >    seconds.
>
> perhaps a silly questions, but should this interval change for each
> keepalive request? I.e. should the UA re-calculate a new random value
> for each keepalive request, or should it only calculate it once and
> then re-use the same value for all subsequent keepalive requests.
>
> in any case this is implementation specific but might be clarified.
clarified (nice catch by the way)

>
>
> > 8.  STUN Keepalive Processing
> >
>
> it seems to me that the logic of detecting if the SIP server supports
> STUN multiplex is too complex and might lead to buggy implementations
> or operational problems.

100% agree with you  - the whole scheme is nuts IMHO

>
> would it not be better for the client to check the Supported: sip-stun
> option tag in the 200 OK response for the REGISTER message?

Well this would not detect if the edge proxy supported it or not but  
I think we should be able to come up with something about this simple  
to solve it.

>
> the behaviour of the SIP server can also change over time, i.e. moving
> from old-style SIP server w/o STUN to support sip-stun, and vice  
> versa.
> the client will check the sip-stun option tag for each 200 OK and  
> either
> enable or disable STUN Binding Discovery.

The behavior should not change without the current flows failing and  
re-registration. Let me walk through an example. First you configure  
out outbound proxy set as old.exmaple.com and everything is running.  
Then you put up the new proxy, configure your outbound set as  
old.example.com,new.emample.com;keepalive=stun but keep incoming  
calls going to old proxy. Once all the UA have updated with this and  
are registered with the both proxies, you change you DNS so incoming  
call go to the new proxy. Once all the new calls are going to the new  
proxy, you change the outbound proxy set to  remove the old proxy and  
once all the UA have updated with that config you take the old proxy  
out of service. At all points in time both incoming and outgoing  
calls would work.

>
>
>
>
>
>
>
>
> General comments:
>
> could we also include some example message flows between the Edge  
> Proxy
> and the registrar?
>
>
> _______________________________________________
> 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

_______________________________________________
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