Subject: [Sip] Registering Multiple 'Contacts'

From: Srinivasan Krishnamoorthy <[email-masked]>
Date: Mon, 12 Jan 2004 12:24:08 -0500 (EST)

Hi,

  Section 10.2.4 of RFC3261 'Refreshing Bindings' says:

  "The UA then issues a REGISTER request for each of its bindings 
  before the expiration interval has elapsed. It MAY combine 
  several updates into one REGISTER request."

  The above seems to indicate that the UAC may send: 
  (forgive the Syntax)

        REGISTER 
        To: [email-masked]
        Contact: sip:[email-masked];expires=3600
        
        200 OK
        
        REGISTER 
        To: [email-masked]
        Contact: sip:[email-masked];expires=3600
        
        200 OK

  This, according to RFC3261, will register both Contact1 and Contact2 
  for [email-masked]. (The server will then use the q parameter
  of the contact for priority among contacts)

  Take a case where a SIP UAC power-cycles or moves without sending 
  an explicit de-REGISTER.  Assume it gets a new IP-address everytime 
  - therefore the 'Contact' will be a new URI every time it sends a 
  REGISTER after a power-cycle.

  If the power-cycle occured before the 'registration expiration interval' 
  elapsed - the Server will essentially be adding 'multiple' bindings
  for this user. Is this correct interpretation?

  Now, is the UAclient mandated to 'deREGISTER' all of its previous contacts 
  before sending its new REGISTER?  Or risk adding multiple 'contacts' 
  at the Server?

  How will the Server prevent against mis-behaved clients in this case?

Thank you very much for any help.
-Srini

_______________________________________________
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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Jan 2004 13:00:25 -0500

>   of the contact for priority among contacts)

Yes.

>   for this user. Is this correct interpretation?

Yes

>   before sending its new REGISTER? 

Its not mandated to do so, but that would probably be a wise thing to do.

 > Or risk adding multiple 'contacts'
>   at the Server?

That is the alternative.

>   How will the Server prevent against mis-behaved clients in this case?

The expiration time bounds the problem, but doesn't eliminate it.
Assume the UAC power cycles, forgets its old address, gets a new one and 
registers it. It will then presumably continue to refresh the new 
address, but not the old one. So the old registration will continue to 
be active until it expires. During that time requests will probably be 
forked to it and the new address, but the ones to the old address will fail.

	Paul

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 15 Jan 2004 14:56:03 -0500

Srinivasan Krishnamoorthy wrote:

>> before the expiration interval has elapsed. It MAY combine   several
>> updates into one REGISTER request."
>>   The above seems to indicate that the UAC may send:   (forgive the
>> Syntax)
>>         REGISTER         To: [email-masked]
>>         REGISTER         To: [email-masked]

> Yes.

My reading is that the results should differ depending on the Call-Id
used in those two REGISTER requests:  

  - If they have different Call-Id values, then the server should
    register both contacts.

  - If they have the same Call-Id value, then the second REGISTER
    should cause the server to replace the first contact with the
    second, so that there would be only

If correct, this adds an additional alternative for the UA - if it can
remember its Call-Id values across contact changes, it can make sure
that old registrations are replaced even before they expire.

-- 
Scott Lawrence        
  Pingtel Corp.

---

From: Srinivasan Krishnamoorthy <[email-masked]>
Date: Thu, 15 Jan 2004 15:13:55 -0500 (EST)

>Assume the UAC power cycles, forgets its old address, gets a new one and registers it. It will then presumably continue to refresh the new address, but not the old one. So the old registration will continue to be active until it expires. During that time requests will probably be forked to it and the new address, but the ones to the old address will fail.
>
>Paul

Another case I could think of is a DHCP environment - where a mobile-ua gets 
different ipaddresses on every power-cycle.

In this case we may have to make sure the DHCP lease timers are longer than
registration duration in the network - or else we could be terminating
a call to an old-IP - that has possibly been granted to another UA that
registered in the interim???

it looks like nothing can be done at the server to 'eliminate' the problem.

Thanks
-Srini

---

From: Takuya Sawada <[email-masked]>
Date: Fri, 16 Jan 2004 09:51:51 +0900

Hi,

>     second, so that there would be only
In my reading of RFC 3261 section 10.3 step 7, Contact URI will be added
to the list irrelevant to Call-ID value if its value is new to the list.

> that old registrations are replaced even before they expire.
If it can remember any value in the previous power-cycle, it may remember
Contact URI and then can remove it with expires=0 explicitly.

Note that assumeing it uses the same "fixed" Call-ID across power-cycle,
it must remember "dynamic" CSeq value in old power-cycle.

Regards,
Takuya

--------
Takuya Sawada
KDDI Corporation (KDDI)
Garden Air Tower, 3-10-10  Iidabashi Chiyoda-ku
Tokyo 102-8460, Japan
Tel: +81-3-6678-2997
Fax: +81-3-6678-0285
[email-masked]

---

From: Takuya Sawada <[email-masked]>
Date: Fri, 16 Jan 2004 10:14:57 +0900

Hi,
> >Assume the UAC power cycles, forgets its old address, gets a new one and registers it. It will then 
presumably continue to refresh the new address, but not the old one. So the old registration will continue 
to be active until it expires. During that time requests will probably be forked to it and the new address, 
but the ones to the old address will fail.
> registered in the interim???
I think that SIP UA which use dynamic IP address SHOULD obey the behaviour 
described above.
Keep DHCP lease timer > SIP registration timer. (any timer used in app level)

> it looks like nothing can be done at the server to 'eliminate' the problem.
I agree.
As a SIP UAS, it can reject the request which has other Request-URI other than
its registered Contact URI with 404, or just ignore such a request.
This can eliminate or reduce the possibility of wrong call termination to the UAS.
Here I assume that user part of Contact URI is unique enough to avoid accidental
collision.

Regards,
Takuya

--------
Takuya Sawada
KDDI Corporation (KDDI)

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Jan 2004 13:42:11 -0500

I agree with Takuya.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Jan 2004 13:44:54 -0500

> Keep DHCP lease timer > SIP registration timer. (any timer used in app level)

I think I would go further and say the UA which uses addresses like this 
MUST do so. If the UA only has temporary ownership of the address, then 
it has no business registering it for a time period when it may not own it.

	Paul

---

From: Scott Lawrence <[email-masked]>
Date: Mon, 19 Jan 2004 14:11:09 -0500

> > it must remember "dynamic" CSeq value in old power-cycle.

I agree with this as well; my point was actually that the correct thing
for the registry in the original inquiry could not actually be
determined based on the messages given, because they did not include the
Call-Id and Cseq values.

Whether or not registrations should be dependant on these values, and
what the right strategy is for a user agent are interesting quesitons
too.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 22 Jan 2004 10:44:17 -0500

>     second, so that there would be only

No, this is not the case. The callid/cseq are used as an ordering 
tool. In the abovoe case, if the Call-ID are the same, both contacts 
are added, and both are marked as having that particular callid, but 
with different cseq. if the Call-id are different, both contacts are 
added, but with different call-id and cseq.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 22 Jan 2004 14:13:32 -0500

> added, but with different call-id and cseq.

I had quite a struggle with this recently; perhaps you could help
clarify what is meant by RFC 3261 sec 10.3 in step 6 when it says:

                                            ...the registrar checks
whether
   the Call-ID agrees with the value stored for each binding.  If
   not, it MUST remove the binding.  

I read that to mean that if my registry contains a binding

   to:        [email-masked]
   call-id: [email-masked]
   cseq:     100
   contact: [email-masked]

and I receive a REGISTER for:

   to:        [email-masked]
   call-id: [email-masked]
   cseq:     10
   contact: [email-masked]

the Call-ID does not agree (making Cseq irrelevant), so shouldn't the
registry remove the binding as directed above?  

[Whatever the answer, I believe that 10.3 is too hard to interpret.  If
I can learn what the right behavior is, I'll be happy to try to draft
text]

-- 
Scott Lawrence        
  Pingtel Corp.

---

From: Takuya Sawada <[email-masked]>
Date: Fri, 23 Jan 2004 09:19:27 +0900

Hi,

>    not, it MUST remove the binding.  
This part, step 6, applies in  the case when REGISTER request contains
one Contact field value that contains the special value "*" and 
Expires that value is zero to remove all bindings.
When adding bindings or removing each binding or refresh bindings,
you must follow step 7.

Regards,
Takuya

--------
Takuya Sawada
KDDI Corporation (KDDI)

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Jan 2004 21:38:38 -0500

You are correct. Step 6 is only for Contact: *.

-Jonathan R.