Subject: Re: [dispatch] New topic proposal for DISPATCH - SIP/XMPP

From: "Rifaat Shekh-Yusef" <[email-masked]>
Date: Fri, 2 Oct 2009 07:00:14 -0400

Hi Simo,
 
> If I understood your scenario correctly, you are proposing to use
separate correlation id's in each direction.
[RSY] Yes, I am proposing the use of separate correlation id's and
utilizing the existing call-id's for that, to avoid the introduction of
new end-to-end id.
 
>That would work as well, but I don't see the reason why Alice would
choose call-id2 as her correlation id, if in any case call-id1 gets to
her UA in F2.
[RSY] Alice would choose call-id2 because this is the Call-ID of her
dialog with the B2BUA.
If Bob wants to initiate an IM session with Alice, he would send
call-id2 as a correlation id which would allow Alice to search her
active calls for a dialog with call-id2.
If Bob sends call-id1 as a correlation id, Alice will not be able to
find a dialog with call-id1 as this is not her dialog.
 
Regards,
 Rifaat

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, September 30, 2009 5:09 AM
To: Shekh-Yusef, Rifaat (BVW:9T16); [email-masked];
[email-masked]; Barnes, Mary (RICH2:AR00);
[email-masked]
Subject: RE: [dispatch] New topic proposal for DISPATCH - SIP/XMPP

Hello Rifaat,
 
sorry for the late reply.
 
If I understood your scenario correctly, you are proposing to use
separete correlation id's in each direction. That would work as well,
but I don't see the reason why Alice would choose call-id2 as her
correlation id, if in any case call-id1 gets to her UA in F2.
 
Simo

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Rifaat Shekh-Yusef
	Sent: 24 September, 2009 18:57
	To: Isomaki Markus (Nokia-CIC/Espoo); Veikkolainen Simo
(Nokia-D/Helsinki); [email-masked]; Mary Barnes;
[email-masked]
	Subject: Re: [dispatch] New topic proposal for DISPATCH -
SIP/XMPP

	Simo,

	If I add a B2BUA to the example that you have in section 7.2:

	Bob                                                B2BUA
Alice

	|                                                      |
|

	| (F1) INVITE                                    | (F2) INVITE
|

	|--------------------------------------------------
>|---------------------------------------------------> |

	| XMPP-Contact: Bob; call-id1           | XMPP-Contact: Bob;
call-id1           |

	|                                                     |
|

	|                                                     |
|

	| (F4) 200 OK                                  | (F3) 200 OK
|

	|<--------------------------------------------------
|<-------------------------------------------------- |

	| XMPP-Contact: Alice; call-id2         | XMPP-Contact: Alice;
call-id2          |

	|                                                     |
|

	Let (F1) INVITE have the correlation-id as the Call-ID of the
dialog between Bob and the B2BUA (call-id1), 

	and (F3) 200 OK have the correlation-id as the Call-ID of the
dialog between the B2BUA and Alice (call-id2).

	Would it not be enough for Bob to send call-id2 to Alice as the
<sip-correlation>? and for Alice to send call-id1 to Bob as the
<sip-correlation>?

	Regards,

	 Rifaat

________________________________

	From: [email-masked] [mailto:[email-masked]]

	Sent: Thursday, September 24, 2009 2:54 AM
	To: Shekh-Yusef, Rifaat (BVW:9T16); [email-masked];
[email-masked]; Barnes, Mary (RICH2:AR00);
[email-masked]
	Subject: RE: [dispatch] New topic proposal for DISPATCH -
SIP/XMPP

	Hi Rifaat,
	 
	In our proposal the correlation works so that:
	1. UAs engaged in a SIP session/dialog exchange an identifier
related to that session (as well as their XMPP full JIDs)
	2. They insert them in the very first XMPP messages they
subsequently exchange, in order to correlate that exchange to be related
to the SIP session.
	 
	The correlation identifier has to be end-to-end, otherwise the
other end won't be able to use it for correlation. Call-ID is often
changed enroute. So, if one endpoint puts it in an XMPP messages as a
reference to a SIP session, the other endpoint won't recognize it as it
has a different Call-ID for the same session.
	 
	Markus

________________________________

		From: ext Rifaat Shekh-Yusef [mailto:[email-masked]]

		Sent: 23 September, 2009 22:57
		To: Veikkolainen Simo (Nokia-D/Helsinki);
[email-masked]; Mary Barnes; [email-masked]
		Cc: Isomaki Markus (Nokia-CIC/Espoo)
		Subject: RE: [dispatch] New topic proposal for DISPATCH

		Simo, Markus,
		 
		I am very interested in this work and I like your
approach.
		 
		I have a question regarding the open issue you have in
section 5.2:
		Why do you require the correlation-value to be an
end-to-end identifier?
		In the case where there is an SBC that creates a new
dialog for the target, would it not be enough for each endpoint to use
the Call-ID of the other dialog as the correlation-value?
		 
		Thanks,
		 Rifaat

________________________________

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
		Sent: Friday, September 04, 2009 8:09 AM
		To: [email-masked]; Barnes, Mary (RICH2:AR00);
[email-masked]
		Cc: [email-masked]
		Subject: [dispatch] New topic proposal for DISPATCH

		Hi,
		 
		We would like to propose a new DISPATCH topic on how SIP
and XMPP can be used together in a complementary fashion.
		 
		We have been working on a solution which combines SIP
based VoIP and XMPP based IM and Presence. The requirements and a
proposed solution is outlined in
http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01
<http://tools.ietf.org/html/draft-veikkolainen-sip-voip-xmpp-im-01> .
		 
		The motivation for this work comes from experience which
shows that most standards based VoIP deployments use SIP. At the same
time, the Extensible Messaging and Presence Protocol (XMPP) is widely
used in instant messaging and presence services. An interesting scenario
arises when a SIP based voice (and video) service is combined together
with an XMPP based instant messaging and presence service. 
		 
		Note that the goal in this work is not SIP-XMPP protocol
translation, but to define protocol extensions and best practises such
that SIP based VoIP and XMPP based IM and presence could be seamlessly
combined and offered to the end user. For rapid deployment, we assume no
changes in the server infrastructure, and instead impose new
requirements and protocol extensions only to the endpoints.
		 
		We would like to get some discussion going on the use
case itself as well as on the solution. Also, we would like to hear you
thoughts on DISPATCH or a new "dispatched" mini-WG as the home for such
work.
		 
		Exact charter proposal and problem statemen is to
follow. 
		 
		Regards,
		Simo and Markus