Subject: [martini] #18: References

From: "martini issue tracker" <[email-masked]>
Date: Mon, 22 Mar 2010 15:07:37 -0000

#18: References
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  john.elwell@…                     
     Type:  defect                     |      Status:  new                               
 Priority:  minor                      |   Milestone:  milestone1                        
Component:  reqs                       |     Version:  1.0                               
 Severity:  In WG Last Call            |    Keywords:                                    
---------------------------------------+------------------------------------
 The requirements document currently references [ETSI TS 182 025]. It may
 be desirable to add additional references.

 From Hans Erik (see http://www.ietf.org/mail-
 archive/web/martini/current/msg01002.html):

 ETSI TS 181 019: "Telecommunications and Internet converged Services and
 Protocols for Advanced Networking (TISPAN); Business Communication
 Requirements".

 ETSI TS 182 023: "Telecommunications and Internet Converged Services and
 Protocols for Advanced Networking (TISPAN); Core and Enterprise NGN
 Interaction Scenarios and Architectural Requirements".

 ETSI TS 182 025 "Telecommunications and Internet converged Services and
 Protocols for Advanced Networking (TISPAN); Business trunking;
 Architecture and functional description

 3GPP I guess it is 24.229. But others are better equipped to answer that
 question.

 Best Regards,
 /Hans Erik van Elburg

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/18>
martini <http://tools.ietf.org/martini/>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 22 Mar 2010 17:59:38 +0100

I am not sure it is worth adding references to ETSI and 3GPP documents that are already referenced from TS 182 025. However, to address the concerns raised in #17, I think the WG needs to have more specific references to particular aspects of these ETSI/3GPP documents that folks think we need compatibility with and where the present gin-00 draft deviates. Whether these need to end up in the requirements document we can decide later, when we have a better understanding.

John 

> -----Original Message-----
> From: martini issue tracker [mailto:[email-masked]] 
> Sent: 22 March 2010 08:08
> To: Elwell, John; [email-masked]
> Cc: [email-masked]
> Subject: [martini] #18: References
> 
> #18: References
>  Reporter:  bernard_aboba@...            |       Owner:  
> john.elwell@...

---

From: <[email-masked]>
Date: Mon, 22 Mar 2010 18:51:12 +0100

The main aspect is the Request-URI for inbound requests. According to TS 182 025, it contains the initial target identity. According to the gin-00 draft it will contain the registered contact.

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Elwell, John
> Envoyé : lundi 22 mars 2010 18:00
> À : [email-masked]; [email-masked]
> Cc : [email-masked]
> Objet : Re: [martini] #18: References
> 
> I am not sure it is worth adding references to ETSI and 3GPP 
> documents that are already referenced from TS 182 025. 
> However, to address the concerns raised in #17, I think the 
> WG needs to have more specific references to particular 
> aspects of these ETSI/3GPP documents that folks think we need 
> compatibility with and where the present gin-00 draft 
> deviates. Whether these need to end up in the requirements 
> document we can decide later, when we have a better understanding.
> 
> John 
> 
> >  The requirements document currently references [ETSI TS 
> 182 025]. It 
> > may  be desirable to add additional references.
> > 
> >  ETSI TS 181 019: "Telecommunications and Internet 
> converged Services 
> > and  Protocols for Advanced Networking (TISPAN); Business 
> > Communication  Requirements".
> > 
> >  ETSI TS 182 023: "Telecommunications and Internet 
> Converged Services 
> > and  Protocols for Advanced Networking (TISPAN); Core and 
> Enterprise 
> > NGN  Interaction Scenarios and Architectural Requirements".
> > 
> >  ETSI TS 182 025 "Telecommunications and Internet converged 
> Services 
> > and  Protocols for Advanced Networking (TISPAN); Business 
> trunking;  
> >  3GPP I guess it is 24.229. But others are better equipped 
> to answer 
> > that  question.
> > 
> >  Best Regards,
> >  /Hans Erik van Elburg
> > 
> > --
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
>

---

From: Dean Willis <[email-masked]>
Date: Mon, 22 Mar 2010 13:21:56 -0500

[email-masked] wrote:
> The main aspect is the Request-URI for inbound requests. According to
> TS 182 025, it contains the initial target identity. According to the
> gin-00 draft it will contain the registered contact.
> 

And the main argument for the gin approach is because that's what is
done in RFC 3261 and devices based on that RFC. This allows "third
party" bulk registration to work with properly configured conventional
PBX (or other UAs) that are otherwise unaware of the extension. The IMS
approach requires a much more significant impact to the installed base.

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Mon, 22 Mar 2010 11:25:38 -0700

Bruno:

I invite you to more carefully examine the example messages in section 
8.2 of the gin-01 draft.

/a

On 3/22/10 10:51 AM, [email-masked] wrote:
>>> Ticket URL:<http://trac.tools.ietf.org/wg/martini/trac/ticket/18>
>>> martini<http://tools.ietf.org/martini/>
>>>
>>>
>>>

---

From: <[email-masked]>
Date: Mon, 22 Mar 2010 19:37:56 +0100

I think I did it already but I should have said "a special contact built as described in the gin draft". In section 8.2 the R-URI contains:"[email-masked]" which is different from the original target identity "sip:[email-masked]". So there is indeed a difference with the 3GPP solution. It does not matter too much in practice because it's an E.164 number and the PBX will likely ignore the domain name anyway. However this prevents extending the solution to other forms of identities.

There is nothing new comapred to previous emails I sent but I was just answering John's request "to have more specific references to particular aspects of these ETSI/3GPP documents that folks think we need compatibility with and where the present gin-00 draft deviates."

> De : Adam Roach [mailto:[email-masked]] 
> Envoyé : lundi 22 mars 2010 19:26
> À : CHATRAS Bruno RD-CORE-ISS
> Cc : [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]
> > The main aspect is the Request-URI for inbound requests. 
> According to TS 182 025, it contains the initial target 
> identity. According to the gin-00 draft it will contain the 
> registered contact.
> >
> >    
> >> [mailto:[email-masked]] De la part de Elwell, 
> John Envoyé : 
> >> lundi 22 mars 2010 18:00 À : [email-masked]; 
> >> [email-masked] Cc : [email-masked] Objet : 
> Re: [martini] 
> >> #18: References
> >>
> >> However, to address the concerns raised in #17, I think 
> the WG needs 
> >> to have more specific references to particular aspects of these 
> >> ETSI/3GPP documents that folks think we need compatibility 
> with and 
> >> where the present gin-00 draft deviates. Whether these 
> need to end up 
> >> in the requirements document we can decide later, when we have a 
> >> better understanding.
> >>
> >> John
> >>
> >>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 22 Mar 2010 14:49:26 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Monday, March 22, 2010 1:51 PM
> 
> The main aspect is the Request-URI for inbound requests. According to TS
> 182 025, it contains the initial target identity. 

Yes, but that's one of the issues I think: it *shouldn't* contain the initial target identity.  Not completely/exactly.  The target identity's host/domain portion was the SSP's domain - the PBX is not in the SSP's domain, is not authoritative for the SSP's domain, and many of them won't accept it with the SSP's domain.  For example, a middlebox often re-writes it to be the PBX's domain/IP. 

I know it's not always done, and not a universal problem - but that's part of the problem - what needs to be signaled is not universally the same/consistent.

For example, if this was a traditional static or rfc3261/3263 "peering" relationship to the PBX, the request-URI would have been re-targeted to the PBX's domain - not left alone.

-hadriel

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 22 Mar 2010 20:25:23 +0100

That thae PBX can not accept the SSP domain is an assumption, there are
several possibilities:
- the arrangement indeed uses the service provider domain, in this case a
pbx using this configuration that receives requests via the trunk should
just happily accepts such requests as it was configured to do so.
- if the arrangenment does use the corporate domain then there is also not
an issue.

The problem is only there if one has to assume that the PBX does not need
any adaptation towards this mechanism, but then it will also not support the
special option tag etc. And for that one has to fallback on the famous
middlebox anyway.

/Hans Erik van Elburg

On Mon, Mar 22, 2010 at 7:49 PM, Hadriel Kaplan <[email-masked]>wrote:

> Yes, but that's one of the issues I think: it *shouldn't* contain the
> initial target identity.  Not completely/exactly.  The target identity's
> host/domain portion was the SSP's domain - the PBX is not in the SSP's
> domain, is not authoritative for the SSP's domain, and many of them won't
> accept it with the SSP's domain.  For example, a middlebox often re-writes
> it to be the PBX's domain/IP.
>
> I know it's not always done, and not a universal problem - but that's part
> of the problem - what needs to be signaled is not universally the
> same/consistent.
>
> For example, if this was a traditional static or rfc3261/3263 "peering"
> relationship to the PBX, the request-URI would have been re-targeted to the
> PBX's domain - not left alone.
>
> -hadriel

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 22 Mar 2010 14:33:35 -0500

As chair - I hope that we have a good discussion, with good remote 
participation, in the Martini session that starts in about 27 minutes ;-)

Spencer

---

From: Adam Roach <[email-masked]>
Date: Mon, 22 Mar 2010 13:17:18 -0700

On 3/22/10 11:37 AM, [email-masked] wrote:
> I think I did it already but I should have said "a special contact built as described in the gin draft". In section 8.2 the R-URI contains:"[email-masked]" which is different from the original target identity "sip:[email-masked]". So there is indeed a difference with the 3GPP solution.

Certainly you recognize that, for the example in section 8.2,  
everything other that the user portion of the URI is under the complete 
and total, unfettered control of the PBX, right? The PBX can put 
whatever it wants in there, even if it is something as inadvisable as 
the SSP's domain. The GIN draft does nothing to prevent it. I don't 
think it's a good idea, but there's nothing to stop it.

/a

---

From: "martini issue tracker" <[email-masked]>
Date: Thu, 25 Mar 2010 19:43:33 -0000

#18: References
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:  john.elwell@…                     
     Type:  defect                     |       Status:  closed                            
 Priority:  minor                      |    Milestone:  milestone1                        
Component:  reqs                       |      Version:  1.0                               
 Severity:  In WG Last Call            |   Resolution:  wontfix                           
 Keywords:                             |  
---------------------------------------+------------------------------------
Changes (by john.elwell@…):

  * status:  new => closed
  * resolution:  => wontfix

Comment:

 We have a reference to TS 182 025, and that in turn references the others,
 so I see no need to add these others to the draft.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/18#comment:1>
martini <http://tools.ietf.org/martini/>