Subject: RE: [Sipping] Requirements for the identification of IMScommunicationservices.

From: <[email-masked]>
Date: Wed, 5 Jul 2006 14:21:36 +0530

Hi Steve, Salvatore,

A few questions on the draft:

1. Is it requirement that the UA should be able to add multiple
Communication Service Identifier and Application Reference in a
REGISTER? If not, how can the UA indicate the capability if it has
multiple Application capabilities?

2. What is the need for Communication Service Identifier and Application
Reference to be set in REGISTER messages?
(req-8 and req-2 respectively). Why does the network need to know the
Applications supported by the UA that is registering? If a call comes in
to the UA, the UA can simply reject the call if it can does support the
Application.
Can you please provide more detail as to why this is needed?

Regards,
Ravi.

--
 
Ravishankar. G. Shiroor
Wipro Technologies, Bangalore.
 
[email-masked]
--

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Stephen Terrill \(MI/EEM\)" <[email-masked]>
Date: Fri, 7 Jul 2006 09:48:06 +0200

Hi Ravi,

To my understanding, I presume that the same requirement would also
exist for the application reference.  Though, in principle, the
application reference should be more transparent to the network and more
visible in the end-points.

Best Regards,

..//Steve 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Wednesday, July 05, 2006 2:59 PM
To: Stephen Terrill (MI/EEM); Salvatore Loreto (JO/LMF);
[email-masked]
Subject: RE: [Sipping] Requirements for the identification of
IMScommunicationservices.

Hi Steve,

Will the Application reference also be used for the purpose that you
have explained?
Will that also be used control the forking rules etc?

Regards,
Ravi.

--

Ravishankar. G. Shiroor

> -----Original Message-----
> From: Stephen Terrill (MI/EEM) [mailto:[email-masked]]

> Sent: Wednesday, July 05, 2006 3:15 PM
> To: RaviShankar Shiroor (WT01 - Product Engineering

> Solutions); Salvatore Loreto (JO/LMF); [email-masked]
> Subject: RE: [Sipping] Requirements for the identification of

> IMScommunicationservices.
>

> Hello Ravi,

> That is a good point that is perhaps a little unclear.  The

> idea for it to be possible for the REGISTER method to be able

> to express the support for multiple CSIDs and application references.
>

> The motivation for this was that if there was devices with

> different capabilities, it would be more efficient to be able

> to steer the terminating INVITES towards the UEs that support

> the communication services.  i.e. this is to make the

> terminating forking case more efficient and avoid unessary

> forking to devices that do not support the required

> communication services.

> This was extended a little in a recent SA2 meeting where it

> was thought that it could be a good idea for the network, at

> registration time, to also inform the terminal of the

> supported/allowed communication services that the terminal

> can use.  This would be to enable a better user experience by

> enabling the terminal to inform the user of means of

> cumminication the user can use (i.e. grey out the invalid

> options etc).

> I hope this addresses your query.
>

> Best regards,

> ..//steve

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Wednesday, July 05, 2006 10:52 AM
> To: Salvatore Loreto (JO/LMF); Stephen Terrill (MI/EEM);

> [email-masked]
> Subject: RE: [Sipping] Requirements for the identification of

> IMScommunicationservices.
>

> 2. What is the need for Communication Service Identifier and

> Application
> Applications supported by the UA that is registering? If a

> call comes in
> to the UA, the UA can simply reject the call if it can does

> support the

> The information contained in this electronic message and any

> attachments
> to this message are intended for the exclusive use of the addressee(s)

> and may contain proprietary, confidential or privileged

> information. If
> you are not the intended recipient, you should not disseminate, 
> distribute or copy this e-mail. Please notify the sender

> immediately and
> destroy all copies of this message and any attachments.
>

> WARNING: Computer viruses can be transmitted via email. The recipient 
> should check this email and any attachments for the presence

> of viruses.
> The company accepts no liability for any damage caused by any virus 
> transmitted by this email.
>

> www.wipro.com

The information contained in this electronic message and any attachments
to this message are intended for the exclusive use of the addressee(s)
and may contain proprietary, confidential or privileged information. If
you are not the intended recipient, you should not disseminate,
distribute or copy this e-mail. Please notify the sender immediately and
destroy all copies of this message and any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient
should check this email and any attachments for the presence of viruses.
The company accepts no liability for any damage caused by any virus
transmitted by this email.

www.wipro.com