[Sip] SIP GW Register

"FCG Huang Qiang \(B300\)" <Qiang.F.Huang@alcatel-sbell.com.cn> Fri, 24 September 2004 10:54 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29066 for <sip-web-archive@ietf.org>; Fri, 24 Sep 2004 06:54:48 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAnpz-0007Mr-7A for sip-web-archive@ietf.org; Fri, 24 Sep 2004 07:02:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAnh2-0007yq-Nu; Fri, 24 Sep 2004 06:52:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAndj-0007E1-LM for sip@megatron.ietf.org; Fri, 24 Sep 2004 06:49:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28799 for <sip@ietf.org>; Fri, 24 Sep 2004 06:49:20 -0400 (EDT)
Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAnkc-0007G8-AK for sip@ietf.org; Fri, 24 Sep 2004 06:56:35 -0400
Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id i8OAiqhi000381 for <sip@ietf.org>; Fri, 24 Sep 2004 18:44:53 +0800 (CST)
Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Fri Sep 24 18:47:42 2004 +0800
Received: from bellnet-mail1.sbell.com.cn ([172.24.208.21]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Fri, 24 Sep 2004 18:47:42 +0800
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Date: Fri, 24 Sep 2004 18:47:42 +0800
Message-ID: <C2DB7F5BC458EA4C8EB46B7A4EFF7E760149C805@bellnet-mail1.sbell.com.cn>
Thread-Topic: Sip Digest, Vol 5, Issue 17
Thread-Index: AcSgw0+kN9XTo64/QfmowwULPpctHwBXTmXA
From: "FCG Huang Qiang (B300)" <Qiang.F.Huang@alcatel-sbell.com.cn>
To: sip@ietf.org
X-OriginalArrivalTime: 24 Sep 2004 10:47:42.0218 (UTC) FILETIME=[EAED1EA0:01C4A223]
X-Spam-Score: 1.9 (+)
X-Scan-Signature: ebd5ffc455fd7bcccba963126e1cf1f5
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] SIP GW Register
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 1.9 (+)
X-Scan-Signature: d67762704726a1bed57e7f4595960d34
Content-Transfer-Encoding: quoted-printable

Question 1:
Accordint to RFC 3261  10.2.2:
Use of the "*" Contact header field value allows a registering UA
to remove all bindings associated with an address-of-record
without knowing their precise values.
So if we use contact * and expire time zero can remove all contact bindings for  the user,
is it or not?

Question 2:
For the registrar discovery  mechanism in the RFC 3261 charpter 10.2.6:
we cand send register message with Request-URI "sip.mcast.net" to find registrar, and how the registrar reply with it? how we can get the registrar information, sucha as domain,ip address and port from the registrar response ?

Question 3:
Not like In H323 GK register mechanism the field termination type can be used to distinguish the GW or termiantion.  In SIP GW can the telephone number prefix be used in the from and to field to send to registrar for telephone number routing? if ok, maybe are there several user to register with registrar for one GW. if not How SIP GW can register with registrar?




-----ԭʼÓʼþ-----
·¢¼þÈË: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]´ú±í
sip-request@ietf.org
·¢ËÍʱ¼ä: 2004Äê9ÔÂ23ÈÕ 0:45
ÊÕ¼þÈË: sip@ietf.org
Ö÷Ìâ: Sip Digest, Vol 5, Issue 17


Send Sip mailing list submissions to
	sip@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/sip
or, via email, send a message with subject or body 'help' to
	sip-request@ietf.org

You can reach the person managing the list at
	sip-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Sip digest..."


Today's Topics:

   1. RE: call stateful ? (Thomas Gal)
   2. RE: Need guidance in call transfer - SIP Based (Umesh Sharma)
   3. [Sip]: SIP and SAML  (Goeman Stefan)
   4. Performance testing tools for SIP entities (brijesh nair)
   5. RE: Performance testing tools for SIP entities
      (Thomas Johansson G (HF/EAB))
   6. Re: Performance testing tools for SIP entities (Bj?rn Gr?nesj?)
   7. Voice Mail (Anurag Kabra)
   8. SIP and MIP addressing (Thibault Renier)
   9. Re: [Sip]: SIP and SAML  (Richard Shockey)


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

Message: 1
Date: Tue, 21 Sep 2004 17:47:06 -0700
From: "Thomas Gal" <ThomasGal@LumenVox.com>
Subject: RE: [Sip] call stateful ?
To: "'vikram'" <vikramb@aftek.com>, "'sip-ietf'" <sip@ietf.org>
Message-ID: <LV-SVR5P22aoCZjL7av00000660@lv-svr.lumenvox.com>
Content-Type: text/plain;	charset="us-ascii"

That means a proxy tracks the transaction ID not the session ID. For example
once the invite has completed a proxy may know nothing about the call that
it connected while for a brief period of time it was "aware" (read
maintaining state) that it was in the middle of an invite command.

-Tom 

> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On 
> Behalf Of vikram
> Sent: Thursday, September 16, 2004 6:26 AM
> To: sip-ietf
> Subject: [Sip] call stateful ?
> 
> hello all,
>               Could anybody  pls explain following from rfc 3261
> 
>   " *A call stateful proxy is always transaction  stateful, 
> but the converse is not necessarily true"*
> 
> 
> regards
> 
> Vikram
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 




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

Message: 2
Date: Wed, 22 Sep 2004 09:53:46 +0530
From: "Umesh Sharma" <umesh_sharma@persistent.co.in>
Subject: RE: [Sip] Need guidance in call transfer - SIP Based
To: <sip-bounces@ietf.org>, "sip" <sip@ietf.org>
Message-ID:
	<HNECIFNGLLKHFHHLCABCCELOCCAA.umesh_sharma@persistent.co.in>
Content-Type: text/plain;	charset="iso-8859-1"



pls see inline.
-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of
Anurag Kabra (by way of Anurag Kabra<anuragk@aftek.com>) (by way of
Anurag Kabra <anuragk@aftek.com>)
Sent: Monday, September 20, 2004 1:24 PM
To: sip@ietf.org
Subject: [Sip] Need guidance in call transfer - SIP Based


I am currently working on VoIP, and I am located in India.
 I have few queries which are bothering me, could you suggest me something
on
 them.  Below are my queries.

1. Do we do retransmission for Refer Request(& Notify) if it doesnot reach
transferee.
>> timeout/retransmission mechanism for refer is same as for bye, non-invite
transactions; when notify times out it is not retransmitted & correp.
subscription should be removed.

2. In a unattended call transfer, when does the dialog end i.e. normally
with a
BYE or Notify(subscriptio-state="terminated").
3. Does the dialog exists even after BYE or subscription-state header in
Notify will terminate the dialog.

2, 3>> my understanding from rfc 3265 bye would not terminate the dialog if
there is subscription on it, subscriber-state="terminated" destroys the
subscription and the dialog if no other application state is associated with
the dialog (more in 3.3.4 rfc 3265). For Call transfer refer goes with in
existing dialog.

4. Is 202 Accepted sent after getting a REFER request, ignored by the
transferor. What is the effect of the response 202 Accepted?
>> it indicates that the subscription has been accepted and that
authorization to proceed with transfer may or may not have been granted.
Also, that a notify will be sent immediately (3.1.4.1). It also creates a
new dialog & subscription if the initial refer was not sent on a
pre-existing dialog otherwise it just creates the new subscription with the
dialog.



This is all for now.  Hope to hear from you soon. Thanks in advance.

Best Regards
 Anurag.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip




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

Message: 3
Date: Wed, 22 Sep 2004 10:30:55 +0200
From: Goeman Stefan <Stefan.Goeman@siemens.com>
Subject: [Sip]: SIP and SAML 
To: "'sip@ietf.org'" <sip@ietf.org>
Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F195692195@hrtades7.atea.be>
Content-Type: text/plain; charset="us-ascii"

Hello,

I was wondering if somebody already reviewed the ID
draft-tschofenig-sip-saml-00.txt.

This draft explicitly mentions that its main goal is not to realize single
sign-on (SSO) functionality as in HTTP. 
However, I wonder if it would not be a good idea to realize SSO
functionality with SAML in SIP. Right now, 3GPP has defined IMS-AKA. This
procedure authenticates the end-user when sending an initial SIP Register
request to the P-CSCF. It must be noted that this is an MNO-centric
approach; the MNO owning both a wireless access network and an IMS domain. 
However, it is not unthinkable that in the future there will exist entities
that will only operate an IMS domain. In this case, end-users will be
authenticated by the (wireless) access network provider. Then, I believe it
makes sense that the access network provider would provide SAML assertions
to the IMS operator providing information on the authentication status of
the end-user. 
How this should be done is unclear to me; I do have some initial ideas
though.

Anybody willing to comment?

Thanks in advance!

Greetings,
Stefan.


Stefan Goeman 
SIEMENS ICM/ICN 
Stefan.Goeman@siemens.com  <mailto:Stefan.Goeman@siemens.atea.be> 
 	

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www1.ietf.org/pipermail/sip/attachments/20040922/c26a946e/attachment.htm

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

Message: 4
Date: Wed, 22 Sep 2004 02:21:31 -0700 (PDT)
From: brijesh nair <briju31@yahoo.com>
Subject: [Sip] Performance testing tools for SIP entities
To: sip@ietf.org
Message-ID: <20040922092131.31780.qmail@web14224.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii

Hi,
  I am looking for good performace testing tools (free
or otherwise) which can be used to test various SIP
entities (e.g B2BUA, Proxy Servers etc.). Can anyone
help on this??

Thanks,
Brijesh




		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com



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

Message: 5
Date: Wed, 22 Sep 2004 11:30:47 +0200
From: "Thomas Johansson G (HF/EAB)" <thomas.g.johansson@ericsson.com>
Subject: RE: [Sip] Performance testing tools for SIP entities
To: "'brijesh nair'" <briju31@yahoo.com>, sip@ietf.org
Message-ID:
	<633A2BAC69E8D411819A00508BCF883C0DA5F66D@esealnt452.al.sw.ericsson.se>
	
Content-Type: text/plain;	charset="iso-8859-1"

Sipp from HP might fulfil your needs (freeware):
http://sourceforge.net/projects/sipp

Sipp is a performance testing tool for the SIP protocol. Its main features are basic SIPStone scenarios, TCP/UDP transport, customizable (xml based) scenarios, dynamic adjustement of call-rate and a comprehensive set of real-time statistics.

BRs
/Thomas

-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of
brijesh nair
Sent: den 22 september 2004 11:22
To: sip@ietf.org
Subject: [Sip] Performance testing tools for SIP entities


Hi,
  I am looking for good performace testing tools (free
or otherwise) which can be used to test various SIP
entities (e.g B2BUA, Proxy Servers etc.). Can anyone
help on this??

Thanks,
Brijesh




		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



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

Message: 6
Date: Wed, 22 Sep 2004 11:32:07 +0200 (CEST)
From: Bj?rn Gr?nesj? <bg@ingate.com>
Subject: Re: [Sip] Performance testing tools for SIP entities
To: brijesh nair <briju31@yahoo.com>
Cc: sip@ietf.org
Message-ID: <Pine.LNX.4.61.0409221129380.16071@conar.ingate.se>
Content-Type: text/plain; charset="iso-8859-1"

Try:
SIPp - sipp.sourceforge.net

//Björn

On Wed, 22 Sep 2004, brijesh nair wrote:

> Hi,
>  I am looking for good performace testing tools (free
> or otherwise) which can be used to test various SIP
> entities (e.g B2BUA, Proxy Servers etc.). Can anyone
> help on this??
>
> Thanks,
> Brijesh
>
>
>
>
>
> _______________________________
> Do you Yahoo!?
> Declare Yourself - Register online to vote today!
> http://vote.yahoo.com
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>

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

Message: 7
Date: Wed, 22 Sep 2004 18:10:31 +0530
From: Anurag Kabra <anuragk@aftek.com>
Subject: [Sip] Voice Mail
To: sip@ietf.org
Message-ID: <200409221810.31676.anuragk@aftek.com>
Content-Type: text/plain;  charset="us-ascii"

Hello Everyone

I need some links detailing Voice Mail Client implementation based on SIP.  
Thank You in advance.

Best Regards
  Anurag.



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

Message: 8
Date: Wed, 22 Sep 2004 16:13:48 +0200
From: "Thibault Renier" <toubix@kom.auc.dk>
Subject: [Sip] SIP and MIP addressing
To: <sip@ietf.org>
Message-ID: <FCEGIMIHPNAAAKBFICFAOEOFCEAA.toubix@kom.auc.dk>
Content-Type: text/plain; charset="iso-8859-1"

Hi all,

I am currently working on integrating SIP in architecture using Mobile IP
for mobility support.
My question concerns the addressing scheme:
At the SIP layer a SIP URI specifies the destination point ("To" field),
going from SIP hop to SIP hop. At the IP layer, the destination address is
usually the same as the current IP address (Care of Address in the MIP
jargon -CoA) that corresponds to the URI used in the "To" (I guess that the
association URI/current IP address of a user is made possible during the
registration procedure). When MIP is used at the IP layer, for
communications from the Correspondent Node (CN) to the Mobile Node (MN), the
destination address is the MN's home address and the packets should be
intercepted by the Home Agent (HA).
1. What is the route in a system combining MIP for mobility support and SIP
for signalling flow? Do the packets go through all the SIP servers/hops
before applying the MIP routing solutions? 
2. What does happen because of the 'conflict' of addresses? (SIP resolves
the URI with the CoA, while IP uses the MN's home address at first)

Thanks for your help
/Tibo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 2004 bytes
Desc: not available
Url : http://www1.ietf.org/pipermail/sip/attachments/20040922/87c2eb8d/winmail.bin

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

Message: 9
Date: Wed, 22 Sep 2004 10:24:46 -0400
From: Richard Shockey <richard@shockey.us>
Subject: Re: [Sip]: SIP and SAML 
To: Goeman Stefan <Stefan.Goeman@siemens.com>, "'sip@ietf.org'"
	<sip@ietf.org>
Message-ID: <6.1.0.6.2.20040922102253.04e18210@joy.songbird.com>
Content-Type: text/plain; charset="us-ascii"

At 04:30 AM 9/22/2004, Goeman Stefan wrote:

>Hello,
>
>I was wondering if somebody already reviewed the ID 
>draft-tschofenig-sip-saml-00.txt.
>
>This draft explicitly mentions that its main goal is not to realize single 
>sign-on (SSO) functionality as in HTTP.
>However, I wonder if it would not be a good idea to realize SSO 
>functionality with SAML in SIP. Right now, 3GPP has defined IMS-AKA. This 
>procedure authenticates the end-user when sending an initial SIP Register 
>request to the P-CSCF. It must be noted that this is an MNO-centric 
>approach; the MNO owning both a wireless access network and an IMS domain.
>
>However, it is not unthinkable that in the future there will exist 
>entities that will only operate an IMS domain. In this case, end-users 
>will be authenticated by the (wireless) access network provider. Then, I 
>believe it makes sense that the access network provider would provide SAML 
>assertions to the IMS operator providing information on the authentication 
>status of the end-user.

IMHO this is only one useful application of SAML to the SIP environment.

I was personally disappointed this document did not recieve more attention 
in SanDiego I hope it will be given a broader hearing in DC.

There are a variety of issues related to SIP security and Identity that 
SAML could solve.


>How this should be done is unclear to me; I do have some initial ideas 
>though.
>
>Anybody willing to comment?
>
>Thanks in advance!
>
>Greetings,
>Stefan.
>
>Stefan Goeman
>SIEMENS ICM/ICN
><mailto:Stefan.Goeman@siemens.atea.be>Stefan.Goeman@siemens.com
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141@fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www1.ietf.org/pipermail/sip/attachments/20040922/cb454d7a/attachment.htm

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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

End of Sip Digest, Vol 5, Issue 17
**********************************

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip