Subject: [sipcore] #41: Why does only "mp" have a value?

From: "sipcore issue tracker" <[email-masked]>
Date: Tue, 31 Aug 2010 18:28:00 -0000

#41: Why does only "mp" have a value?
---------------------------------+------------------------------------------
 Reporter:  worley@…             |       Owner:            
     Type:  enhancement          |      Status:  new       
 Priority:  critical             |   Milestone:  milestone1
Component:  rfc4244bis           |     Version:            
 Severity:  In WG Last Call      |    Keywords:            
---------------------------------+------------------------------------------
 There seems to be no reason to restrict the "mp-value", the information
 regarding the predecessor request-URI to a newer request-URI, to only "mp"
 mappings.  In particular, if a redirect server implements an "rc" mapping,
 it could be difficult for the UAS to determine why it received the
 request:

 {{{
    Alice   atlanta.example.com  biloxi.example.com   Carol
    |                |                |                |
    |   INVITE sip:[email-masked]    |                |
    |--------------->|                |                |
    | History-Info: <sip:[email-masked]>;index=1      |
    |                |                |                |
    |                |   INVITE sip:[email-masked]    |
    |                |--------------->|                |
    | History-Info: <sip:[email-masked]>;index=1      |
    | History-Info: <sip:[email-masked]>;index=1.1    |
    |                |                |                |
    |                |   300          |                |
    |                |   Contact: <sip:[email-masked]>;mp
    | History-Info: <sip:[email-masked]>;index=1      |
    | History-Info: <sip:[email-masked]>;index=1.1    |
    |                |<---------------|                |
    |                |                |                |
    |                |   INVITE sip:[email-masked]
    |                |--------------->|                |
    | History-Info: <sip:[email-masked]>;index=1      |
    | History-Info: <sip:[email-masked]>;index=1.1    |
    | History-Info: <sip:[email-masked]>;index=1.2;mp=1.1
    |                |                |                |
    |                |   300          |                |
    |                |   Contact: <sip:[email-masked]>;rc
    | History-Info: <sip:[email-masked]>;index=1      |
    | History-Info: <sip:[email-masked]>;index=1.1    |
    | History-Info: <sip:[email-masked]>;index=1.2;mp=1.1
    |                |<---------------|                |
    |                |                |                |
    |                |   INVITE sip:[email-masked]    |
    |                |-------------------------------->|
    | History-Info: <sip:[email-masked]>;index=1      |
    | History-Info: <sip:[email-masked]>;index=1.1    |
    | History-Info: <sip:[email-masked]>;index=1.2;mp=1.1
    | History-Info: <sip:[email-masked]>;index=1.3;rc |
    |                |                |                |
 }}}

 (In this case, Carol might know to look for sip:[email-masked] and
 trace its origin, but if we add a further retargeting and registration
 lookup cycle for a different user in the middle, we can defeat that
 strategy.)

 It would seem useful to allow the "rc" parameter to have a value as well.
 And given that some 3xx Contacts will have neither "mp" or "rc", but the
 "origin" value would still be useful for a UAS to see, it seems desirable
 to split off the "origin" value to another parameter which would be
 applied regardless of whether "mp" or "rc" applies.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/41>
sipcore <http://tools.ietf.org/sipcore/>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 31 Aug 2010 20:50:39 -0400

Uh oh... I think your example shows another problem too.

Suppose atlanta proxy gets a request for Bob as you show, and for Bob it internally has 2 potential routes.  It tries the first, and gets diverted to Carol, as in your example... but Carol fails.  So the atlanta proxy recurses the failure and tries the second route, which is still for *Bob*.  The UAS will get this:
History-Info: <sip:[email-masked]>;index=1 
History-Info: <sip:[email-masked]>;index=1.1
History-Info: <sip:[email-masked]>;index=1.2;mp=1.1
History-Info: <sip:[email-masked]>;index=1.3;rc
History-Info: <sip:[email-masked]>;index=1.4
History-Info: <sip:[email-masked]>;index=1.4.1;rc

If you receive that as a UAS, you don't know whether it was diverted to Carol and then reached you as being for Carol, or whether it's back to being for Bob. 
Ugh.

It's a hack, but perhaps a diversion/"mp" should cause a new sub-level.  Like this:
History-Info: <sip:[email-masked]>;index=1 
History-Info: <sip:[email-masked]>;index=1.1
History-Info: <sip:[email-masked]>;index=1.1.1;mp=1.1
History-Info: <sip:[email-masked]>;index=1.1.2;rc
History-Info: <sip:[email-masked]>;index=1.2
History-Info: <sip:[email-masked]>;index=1.2.1;rc

-hadriel

On Aug 31, 2010, at 2:28 PM, sipcore issue tracker wrote:

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore