Hi Marco,
RFC 3261 mentions that any proxy should not be sending a
provisional response for a non-Invite request.
8.2.6.1 Sending a Provisional Response
"One largely non-method-specific guideline for the generation of
responses is that UASs SHOULD NOT issue a provisional response for a
non-INVITE request. Rather, UASs SHOULD generate a final response to
a non-INVITE request as soon as possible."
To answer your third question I could think of scenario in which UAC
want to update the Session info if it hasn't received the 200 OK. So the
logic will involve checking of dialog state. If its early send an
"UPDATE" else send an Invite.
Regards,
Rahul
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Monday, June 19, 2006 11:30 PM
To: [email protected]
Subject: Sip-implementors Digest, Vol 39, Issue 29
Send Sip-implementors mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Sip-implementors digest..."
Today's Topics:
1. Re: SIP authentication credentials (Nataraju A B)
2. Re: SIP authentication credentials (Ramachandran Iyer)
3. Re: SIP authentication credentials ([EMAIL PROTECTED])
4. What is the meaning of Destiantion Hold in SIP (Henry Jacobs)
5. Re: SIP authentication credentials (Scott Lawrence)
6. Re: SIP authentication credentials (Nataraju A B)
7. query about Calling ID (Michael Putter)
8. Dialog creation (Marco Ambu)
9. SIP INFO implementation (Manpreet Singh)
----------------------------------------------------------------------
Message: 1
Date: Mon, 19 Jun 2006 11:32:07 +0530
From: "Nataraju A B" <[EMAIL PROTECTED]>
Subject: Re: [Sip-implementors] SIP authentication credentials
To: "'Scott Lawrence'" <[EMAIL PROTECTED]>, "'Clinkert
Jack-G3295C'" <[EMAIL PROTECTED]>
Cc: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
Comments inline...
Thanks & Regards,
Nataraju A.B.
> -----Original Message-----
> From: [EMAIL PROTECTED]
[mailto:sip-implementors-
> [EMAIL PROTECTED] On Behalf Of Scott Lawrence
> Sent: Sunday, June 18, 2006 3:27 AM
> To: Clinkert Jack-G3295C
> Cc: [email protected]
> Subject: Re: [Sip-implementors] SIP authentication credentials
>
> On Fri, 2006-06-16 at 14:14 -0500, Clinkert Jack-G3295C wrote:
> > Are SIP authentication credentials typically cached across multiple
> > dialogs? Seems (to me anyway) that RFC 3261 is vague on the
subject.
> > It is talked about in Section 22.2:
> >
> > Once authentication credentials have been supplied
> > (either directly by the user, or discovered in an internal
keyring),
> > UAs SHOULD cache the credentials for a given value of the To
header
> > field and "realm" and attempt to re-use these values on the next
> > request for that destination. UAs MAY cache credentials in any
way
> > they would like.
> >
> >
> > Seems the benefit to cache credentials across multiple dialogs is to
> > reduce traffic (can avoid the challenge/response messaging). Seems
a
> > drawback is that the "copy attack" risk associated with digest
> > authentication is increased however. In other words, the longer
cached
> > credentials are allowed to be used, the greater the availaibility
for an
> > attacker to use them.
>
> Cacheing the credentials refers to not prompting the user for them -
> something few UAs do anyway. Whether or not you must provide an
> Authorization or Proxy-Authorization header in any given request is
> purely up to the server. Once you have a challenge, there is nothing
to
> prevent you from preemptively inserting the authorization in
subsequent
> messages in the dialog to prevent the extra round-trip. Whether or
not
> the server will accept those (when it decides to send you a new nonce)
> is up to the server.
>
>
[ABN] any client/server can decide to cache the credentials for some
duration to challenge/response due to authentication procedures.
I personally feel its better to cache the credentials for a short
duration. Hence we can reduce the request/response transactions if the
messaging happens very often. Once the time expired then that set of
credentials become stale, after that message would be authenticated as
new requests.
Just for instance, assume (OMA POC) client is synchronizing with server,
this generate a series of HTTP requests. If the credentials were cached,
then it reduces a large % of messaging.
> --
> Scott Lawrence tel:+1-781-938-5306;ext=162 or
sip:[EMAIL PROTECTED]
> sipXpbx project coordinator - SIPfoundry
http://www.sipfoundry.org/sipX
> Chief Architect - Pingtel Corp. http://www.pingtel.com/
>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
------------------------------
Message: 2
Date: Mon, 19 Jun 2006 01:56:52 -0700 (PDT)
From: Ramachandran Iyer <[EMAIL PROTECTED]>
Subject: Re: [Sip-implementors] SIP authentication credentials
To: Clinkert Jack-G3295C <[EMAIL PROTECTED]>,
[email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=iso-8859-1
inline...
Clinkert Jack-G3295C <[EMAIL PROTECTED]> wrote: Are SIP
authentication credentials typically cached across multiple
dialogs? Seems (to me anyway) that RFC 3261 is vague on the subject.
It is talked about in Section 22.2:
Once authentication credentials have been supplied
(either directly by the user, or discovered in an internal keyring),
UAs SHOULD cache the credentials for a given value of the To header
field and "realm" and attempt to re-use these values on the next
request for that destination. UAs MAY cache credentials in any way
they would like.
Seems the benefit to cache credentials across multiple dialogs is to
reduce traffic (can avoid the challenge/response messaging). Seems a
drawback is that the "copy attack" risk associated with digest
authentication is increased however. In other words, the longer cached
credentials are allowed to be used, the greater the availaibility for an
attacker to use them.
[Rama] I agree with u.. its purely a matter of balance between the
overhead associated with non-cacheing compared to the benefits on the
security front. So this i guess, this should be a call made by the
operator and should be a flexible parameter from an implemenation
stand-point. That way, you allow the operator to decide of how much
non-cacheing he can bear (meaning,,how small of a cache time he can
accomodate for,,which will provide for more security).
What is the "industry" standard implementation? How do some of the more
popular user agent toolkits handle this?
Thanks
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
---------------------------------
Sneak preview the all-new Yahoo.com. It's not radically different. Just
radically better.
------------------------------
Message: 3
Date: Mon, 19 Jun 2006 16:02:14 +0530
From: <[EMAIL PROTECTED]>
Subject: Re: [Sip-implementors] SIP authentication credentials
To: <[email protected]>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
>
>
> Seems the benefit to cache credentials across multiple
> dialogs is to reduce traffic (can avoid the
> challenge/response messaging). Seems a drawback is that the
> "copy attack" risk associated with digest authentication is
> increased however. In other words, the longer cached
> credentials are allowed to be used, the greater the
> availaibility for an attacker to use them.
>
I think this also depends on the kind of link established between the
proxy and the UA.
Fro example, If an IPSEC tunnel is established between the UA and the
proxy, proxy can retain the credentials across the dialogs as long as
the same link is being used to establish the new dialogs.
Regards,
Ravi.
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
------------------------------
Message: 4
Date: Mon, 19 Jun 2006 16:26:33 +0530
From: "Henry Jacobs" <[EMAIL PROTECTED]>
Subject: [Sip-implementors] What is the meaning of Destiantion Hold in
SIP
To: [email protected]
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi All
What is the meaning of Destination Hold ? in SIP
Thanks
Henry
------------------------------
Message: 5
Date: Mon, 19 Jun 2006 07:12:31 -0400
From: Scott Lawrence <[EMAIL PROTECTED]>
Subject: Re: [Sip-implementors] SIP authentication credentials
To: Nataraju A B <[EMAIL PROTECTED]>
Cc: [email protected], 'Clinkert Jack-G3295C'
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain
On Mon, 2006-06-19 at 11:32 +0530, Nataraju A B wrote:
> I personally feel its better to cache the credentials for a short
> duration. Hence we can reduce the request/response transactions if the
> messaging happens very often. Once the time expired then that set of
> credentials become stale, after that message would be authenticated as
> new requests.
If you mean that the server should not check credentials for some
requests, that is certainly within the rules (whether or not it is a
good idea depends on circumstances).
> Just for instance, assume (OMA POC) client is synchronizing with
server,
> this generate a series of HTTP requests. If the credentials were
cached,
> then it reduces a large % of messaging.
If the client and server are doing things correctly, any number of
messages in HTTP and any number in the same dialog in SIP can be
authenticated with only one challenge and one extra request.
--
Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:[EMAIL PROTECTED]
sipXpbx project coordinator - SIPfoundry
http://www.sipfoundry.org/sipX
Chief Architect - Pingtel Corp. http://www.pingtel.com/
------------------------------
Message: 6
Date: Mon, 19 Jun 2006 18:24:06 +0530
From: "Nataraju A B" <[EMAIL PROTECTED]>
Subject: Re: [Sip-implementors] SIP authentication credentials
To: "'Scott Lawrence'" <[EMAIL PROTECTED]>
Cc: [email protected], 'Clinkert Jack-G3295C'
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
Comments inline...
Thanks & Regards,
Nataraju A.B.
> -----Original Message-----
> From: Scott Lawrence [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 19, 2006 4:43 PM
> To: Nataraju A B
> Cc: 'Clinkert Jack-G3295C'; [email protected]
> Subject: RE: [Sip-implementors] SIP authentication credentials
>
> On Mon, 2006-06-19 at 11:32 +0530, Nataraju A B wrote:
>
> > I personally feel its better to cache the credentials for a short
> > duration. Hence we can reduce the request/response transactions if
the
> > messaging happens very often. Once the time expired then that set of
> > credentials become stale, after that message would be authenticated
as
> > new requests.
>
> If you mean that the server should not check credentials for some
> requests, that is certainly within the rules (whether or not it is a
> good idea depends on circumstances).
>
[ABN] I mean to say, client/server can cache the credentials for some
time so that the credentials carried in the next incoming request
matches the cached credentials, then client/server can assume it's an
authenticated request and no need to authenticate that request.
> > Just for instance, assume (OMA POC) client is synchronizing with
server,
> > this generate a series of HTTP requests. If the credentials were
cached,
> > then it reduces a large % of messaging.
>
> If the client and server are doing things correctly, any number of
> messages in HTTP and any number in the same dialog in SIP can be
> authenticated with only one challenge and one extra request.
>
[ABN] True, but we can reduce the too many message transactions if we
can cache the credentials for a short time...
> --
> Scott Lawrence tel:+1-781-938-5306;ext=162 or
sip:[EMAIL PROTECTED]
> sipXpbx project coordinator - SIPfoundry
http://www.sipfoundry.org/sipX
> Chief Architect - Pingtel Corp. http://www.pingtel.com/
------------------------------
Message: 7
Date: Mon, 19 Jun 2006 17:43:44 +0300
From: "Michael Putter" <[EMAIL PROTECTED]>
Subject: [Sip-implementors] query about Calling ID
To: <[email protected]>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="windows-1255"
Hi,
I am working on gateway V5.2 to SIP.
What is usual used way to pass Calling ID via SIP toward SIP UA. The one
way is "Display Name" but I see that a part of SIP UA does not display
"Display Name" value and try to display User Name instead or together.
Thanks, Michael.
------------------------------
Message: 8
Date: Mon, 19 Jun 2006 17:29:30 +0200
From: Marco Ambu <[EMAIL PROTECTED]>
Subject: [Sip-implementors] Dialog creation
To: SIP-implementors mailing list <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Hi,
I'd like to receive some clarifications about dialogs.
1) Can methods other than INVITE send 1xx responses with to tag that
create a dialog?
2) If answer to question #1 is yes, then is the UAC/UAS behaviour the
same one of INVITE (that is, create an early dialog for each 1xx
repsonse with to tag and then after receiving 2xx response remove all
early dialogs and create a confirmed dialog)?
3) Is there any reason to keep early dialogs in the dialog's map
(considering that cannot be used to create a new request)?
Thanks
--
Marco Ambu
Abbeynet S.p.A. (www.abbeynet.it)
------------------------------
Message: 9
Date: Mon, 19 Jun 2006 13:55:48 -0400
From: Manpreet Singh <[EMAIL PROTECTED]>
Subject: [Sip-implementors] SIP INFO implementation
To: [email protected]
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain
Hi
How is the support for SIP INFO negotiated between 2 UACs? The initial
INVITE carries the Allow and Call-Info headers? Is that all what is
needed
to Offer the support for INFO?
Also what exact syntax is used for negotiating INFO for out of band
DTMF?
The actual payload carried for the INFO is the telephony-events?
A call example with an actual message exchange would be truely
appreciated.
Thanks
Manpreet
------------------------------
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
End of Sip-implementors Digest, Vol 39, Issue 29
************************************************
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
