Subject: Re: [dispatch] About Final Charter for Session-ID:

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 6 Jul 2010 04:22:03 -0400

Right, my intention was to NOT impact/affect/include dialog-matching, or anything but troubleshooting.  But of course a charter and WG is a consensus-based decision, not mine, so if others feel they want more they can argue for it.

-hadriel

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, June 29, 2010 9:08 PM
To: [email-masked]
Cc: Hadriel Kaplan
Subject: About Final Charter for Session-ID:

Hi,

By the charter and the original text named draft-kaplan-sip-session-id-02, this work is just focused on troubleshooting usage.

But I was told that *someone* want to use this session-id in Replace header usage, to do dialog-matching. I think this would be UPDATE of RFC3891.

So, I'd like to confirm that this charter and coming draft would not do such thing normatively.

Thanks,

Gao

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : [email-masked]
===================================

--------------------------------------------------------

ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.

This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: [email-masked]
Date: Wed, 7 Jul 2010 13:43:39 +0800

Hi Hadriel,

> Right, my intention was to NOT impact/affect/include dialog-
> matching, or anything but troubleshooting. 

This is my understanding of the charter and the text. Then, I am right at 
this point.

> But of course a charter 
> and WG is a consensus-based decision, not mine, so if others feel 
> they want more they can argue for it.

Quit true. And I will seek time to make a more detailed discussion for 
this topic. And I hope people who care about "replace header's 
dialog-matching problem" join in this discussion then.

Gao

> By the charter and the original text named draft-kaplan-sip-session-
> id-02, this work is just focused on troubleshooting usage. 
> 
> But I was told that *someone* want to use this session-id in Replace
> header usage, to do dialog-matching. I think this would be UPDATE of 
RFC3891.
> ZTE Information Security Notice: The information contained in this 
> mail is solely property of the sender's organization. This mail 
> communication is confidential. Recipients named above are obligated 
> to maintain secrecy and are not permitted to disclose the contents 
> of this communication to others.
> This email and any files transmitted with it are confidential and 
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please 
> notify the originator of the message. Any views expressed in this 
> message are those of the individual sender.

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 7 Jul 2010 06:03:36 -0400

Gao,
Have you taken a look at the email thread about session-id and dialog-matching, starting at the following email message?:
http://www.ietf.org/mail-archive/web/dispatch/current/msg01658.html
I think a replaces usage would have the same issues.

-hadriel

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 07, 2010 1:44 AM
To: Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [dispatch] About Final Charter for Session-ID:

Hi Hadriel,

> matching, or anything but troubleshooting.

This is my understanding of the charter and the text. Then, I am right at this point.

> they want more they can argue for it.

Quit true. And I will seek time to make a more detailed discussion for this topic. And I hope people who care about "replace header's dialog-matching problem" join in this discussion then.

Gao

> header usage, to do dialog-matching. I think this would be UPDATE of RFC3891.
>

---

From: [email-masked]
Date: Wed, 7 Jul 2010 18:39:27 +0800

Hi Hadriel,

I met the same problem as you showed in your mail(relating 3GPP's 
conference service) in our real IMS deployment. The original and directly 
idea for me is the same as the prosposal showed in your mail, to invent a 
new header to do dialog-matching beyond B2BUA equipment(I even have a 
patent for a new header to do dialog-matching).

But why now I reject the way? There are two main reasons here:

1. This work is UPDATE RFC3891(as I said before). And even we make this 
*potential UPDATE RFC3891 Draft/RFC*, how may UAs would support it, and I 
think there still would be a serious interworking issue.

2. Philosophy and methodology:
As we know, basic SIP RFCs(standard track) only define rules about UAC/UAS 
and proxy. There's no normative definition about B2BUA(RFC3725 is BCP 
level). In fact, B2BUA is implementation level usage of standard track SIP 
RFCs.
So, I don't think it is appropriate to use B2BUA's implementation level 
problem as reason for demanding standard track SIP RFC's correction.

Thanks,

Gao

Hadriel Kaplan <[email-masked]> 
2010-07-07 18:03

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
RE: [dispatch] About Final Charter for Session-ID:

Gao,
Have you taken a look at the email thread about session-id and 
dialog-matching, starting at the following email message?:
http://www.ietf.org/mail-archive/web/dispatch/current/msg01658.html
I think a replaces usage would have the same issues.
 
-hadriel

From: [email-masked] [mailto:[email-masked]] On 
Behalf Of [email-masked]
Sent: Wednesday, July 07, 2010 1:44 AM
To: Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [dispatch] About Final Charter for Session-ID:

Hi Hadriel, 

Gao 

RFC3891.
 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

---

From: [email-masked]
Date: Wed, 7 Jul 2010 19:12:17 +0800

For all people care about the Replace header problem,

As the problem origin is B2BUA equipment, the solution should be limited 
to/around itself, to keep things simple. It is not proper to ask other 
*innocent* network element/equipment to do more for it.

And people who familiar with 24.229 know that routing B2BUA AS should 
change the dialog information in the replace header from dialog1 to 
dialog2(dialog1/2 means general two dialog on the B2BUA's two sides). 

So, we can extend the changing-dialog-information rule from routing B2BUA 
AS to other B2BUA equipmemt, such as BGW/SBC.

+----+      +-----+      +----+      +-----+      +----+
  |UA-A|      |B2BUA|      | AS |      |B2BUA|      |UA-B|
  +----+      +-----+      +----+      +-----+      +----+
    |            |            |           |            |
    |INVITE      |            |           |            |
    |callid:1a   |callid:1b   |callid:1c  |callid:1d   |
    |----------->|----------->|---------->|----------->|
    |sessid:1    |sessid:1    |sessid:1   |sessid:1    |
    |            |            |           |            |
    |INVITE      |            |           |            |
    |callid:2a   |callid:2b   |           |            |
    |----------->|----------->|           |            |
    |sessid:2    |sessid:2    |re-INVITE  |            |
    |RL<sessid:1>|RL<sessid:1>|callid:1c  |callid:1d   |
    |            |            |---------->|----------->|
    |            |            |sessid:1   |sessid:1    |
    |            |            |           |            |

Further, in our real IMS deployment use cases, I find there's still one 
special situation for routing B2BUA AS. As we know, access/edge network 
elements, such as BGW, SBC are always in the call signalling path, no 
matter for callid:ia or callid:2a. But one routing B2BUA AS would in the 
call signalling path for callid:1a, while absent for the call signalling 
path for callid:1b. One example is: when UA-A call UA-B, there would be 
one AS for UA-A's originating-supplement-service. But the AS would not be 
triggered when UA-A call the conference PSI.

For this special situation, my solution is to make the AS would be 
triggered when the new INVITE(callid:2a) has a replace header with 
dialog-information as callid:1a. And this complys with current iFC 
mechanism. The new thing is the routing B2BUA should modify the UA-A's iFC 
to guarantee it would be triggered in the new call's signalling path, and 
do the changing the dialog information work as defined in 24.229.

Thanks,

Gao

收件人

Gao,
 
-hadriel

Hi Hadriel, 

Gao 

RFC3891.
system.

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 7 Jul 2010 17:10:35 +0530

That's one the primary reasons why I think IETF should have at least a BEHAVE-like WG for B2BUAs/SBCs.
 
Muthu
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 07, 2010 4:09 PM
To: Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [dispatch] About Final Charter for Session-ID:

Hi Hadriel, 

I met the same problem as you showed in your mail(relating 3GPP's conference service) in our real IMS deployment. The original and directly idea for me is the same as the prosposal showed in your mail, to invent a new header to do dialog-matching beyond B2BUA equipment(I even have a patent for a new header to do dialog-matching). 

1. This work is UPDATE RFC3891(as I said before). And even we make this *potential UPDATE RFC3891 Draft/RFC*, how may UAs would support it, and I think there still would be a serious interworking issue. 

2. Philosophy and methodology: 
As we know, basic SIP RFCs(standard track) only define rules about UAC/UAS and proxy. There's no normative definition about B2BUA(RFC3725 is BCP level). In fact, B2BUA is implementation level usage of standard track SIP RFCs. 
So, I don't think it is appropriate to use B2BUA's implementation level problem as reason for demanding standard track SIP RFC's correction. 

Thanks, 

Gao 

Gao, 
Have you taken a look at the email thread about session-id and dialog-matching, starting at the following email message?: 
http://www.ietf.org/mail-archive/web/dispatch/current/msg01658.html <http://www.ietf.org/mail-archive/web/dispatch/current/msg01658.html>  
I think a replaces usage would have the same issues. 
  
-hadriel 

Hi Hadriel, 

Gao

---

From: [email-masked]
Date: Wed, 7 Jul 2010 19:46:58 +0800

Muthu,

Yes. I agree with these words in your mail:
"Due to lack of well defined guidelines and best current practices many 
SBC implementations break end-to-end features"

So, I think any B2BUA problem should make it solution in-scope of the 
B2BUA itself or just around it.

Thanks,

Gao

"Muthu ArulMozhi Perumal (mperumal)" <[email-masked]> 
2010-07-07 19:40

收件人
<[email-masked]>, "Hadriel Kaplan" <[email-masked]>
抄送
<[email-masked]>
主题
RE: [dispatch] About Final Charter for Session-ID:

That's one the primary reasons why I think IETF should have at least a 
BEHAVE-like WG for B2BUAs/SBCs.
 
Muthu

Hi Hadriel, 

Thanks, 

Gao 

收件人

Gao, 
  
-hadriel 

Hi Hadriel, 

Gao 

RFC3891.
system.