Subject: [martini] martini-gin-02: multiple contacts

From: Martien Huysmans <[email-masked]>
Date: Fri, 21 May 2010 08:29:37 +0200

Martini-gin-02, chapter 5.1 contains the following text
  Second, in at least one "Contact" header field, it must include a
   Contact URI that contains the URI parameter "bnc", and no user
   portion (hence no "@" symbol).

Assume that 2 Contact header fields are present, one with bnc and one without.
This implies that for inbound SIP Request, forking would take place at the SSP.

1) Is that always wanted behaviour, e.g. consider SUBSCRIBE in ch 6.

2) What is the use case that people had in mind, when adding this possibility?

Regards Martien

---

From: Adam Roach <[email-masked]>
Date: Fri, 21 May 2010 16:54:18 -0500

> This implies that for inbound SIP Request, forking would take place at 

Not "would." "Might." What a proxy does with registration data when a 
call arrives is always subject to local policy. So qsking about whether 
forking is "the right thing to do" doesn't make much sense. Proxies will 
do it if it's the right thing to do /according to their local policy/, 
and they won't if it isn't.

> 2) What is the use case that people had in mind, when adding this 

We didn't add it -- it is implict in the use of the REGISTER method -- 
we simply don't prohibit it.

/a

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 27 May 2010 00:03:36 +0200

On Fri, May 21, 2010 at 11:54 PM, Adam Roach <[email-masked]> wrote:
> Not "would." "Might." What a proxy does with registration data when a call
> arrives is always subject to local policy. So qsking about whether forking
> is "the right thing to do" doesn't make much sense. Proxies will do it if
> it's the right thing to do according to their local policy, and they won't
> if it isn't.
>

[HE] The text in 5.2 implies that if there is one contact header with
the bnc parameter then for all the contacts listed in the REGISTER the
GIN behaviour applies. Is that intended?

> We didn't add it -- it is implict in the use of the REGISTER method -- we
> simply don't prohibit it.
>

[HE] It is explictly mentioned (indicated) in the text. Hence the
question. I think we would need to explain what it means in this
particular case. Does it make sense at all? Ca it be used for
redundant connections? etc.