Thanks all,
Rich
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Friday, July 15, 2005 9:41 AM
To: [email protected]
Subject: Sip-implementors Digest, Vol 28, Issue 28
Send Sip-implementors mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.cs.columbia.edu/mailman/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: proxy servers multiple realm (Paul Kyzivat)
2. RE:Query on Hold call (sathya shankar)
3. RE: Query on Hold call (Paliakkara, Geo Paul (Geo))
4. Re: Query on Hold call (Paul Kyzivat)
5. Re: New offer in 200 OK of INVITE (Paul Kyzivat)
----------------------------------------------------------------------
Message: 1
Date: Fri, 15 Jul 2005 08:57:47 -0400
From: Paul Kyzivat <[EMAIL PROTECTED]>
Subject: Re: [Sip-implementors] proxy servers multiple realm
To: Peili Xu <[EMAIL PROTECTED]>
Cc: "'Arunachalam Venkatraman \(arunvenk\)'" <[EMAIL PROTECTED]>,
[email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii; format=flowed
I've been trying to ignore this, but guess I will jump in.
In what I would consider a "normal" case, a server that wants to
authenticate a request will either have exactly one realm that it uses,
or else will at least be able to select a realm based on information
(not authentication information) in the request.
For example, normally I think authentication will be done on outgoing
requests. Something in the request (e.g. From or P-Preferred-Identity)
will indicate the identity the sender wants to assert. Then the realm
would be chosen to be consistent with that.
It is *possible* (though IMO not likely) that authentication would be
required on the terminating side. (You must know the magic password to
call this person.) In that case, the realm might be chosen based on the
target address.
And I suppose that some server in the middle (perhaps involved based on
an explicit Route header) might provide some service and want to
authenticate before providing the service. It could make a decision of
realm as if it was part of either the originating or terminating side,
as above, or neither in which case I guess it will just have to decide
in its own way.
I don't think the concept of challenging based on all the realms the
server supports, and expecting the caller to pick one, works. If the
caller receives a 407 Proxy Authenticate with multiple challenges, I
believe it will think it must provide credentials for *each* challenge,
rather than just picking one. (Normally this case would arise because of
challenges from multiple independent proxies.) Perhaps the situation is
different for a 401 response, but I doubt it.
So I think, one way or another, that the challenging server must make
its own decision about what realm to challenge for.
Paul
Peili Xu wrote:
Yes, I totally agree with what you mentiond.
But I think the problem we are discussing is about whether to provide
auth
related info in initial request or not. If the server have no idea
about the
destination realm the user want to log in ,it have to select a default
one
to challenge?
So if applicable, it`s better to provide auth info at lease user and
realm
in initial request.
I don`t know if I have missed sth.
Thanks and best reguards!
Peili Xu
_________________________________________________________________
Peili Xu
System Engineer Core Network Research & Standard Department
Huawei Technologies Co., Ltd
Email: [EMAIL PROTECTED]
Phone: +86-755-28780808
Website: www.huawei.com
_________________________________________________________________
-----Original Message-----
From: Amarendra Kumar [mailto:[EMAIL PROTECTED]
Sent: Friday, July 15, 2005 1:30 PM
To: Peili Xu
Cc: Arunachalam Venkatraman (arunvenk); Dale Worley;
[email protected]
Subject: Re: [Sip-implementors] proxy servers multiple realm
Proxy server can configure itself for multiple realms. This can be
based on the resource
usage / groups/ subscriber basis. If for a user there can be more than
one realms
configured. Thus when ever request comes for the server it will
challenge with realms
configured. This is up to the end point how he will behave towards
it, means to say
end point can send authentication credentials to more than one realms
depending upon
the configuration property.
On 7/15/05, Peili Xu <[EMAIL PROTECTED]> wrote:
Carring Authorization even in initial request will ease the
processing of
server. To provide "user" and "realm" is the point. Other files like
nouce,
response ... is not applicable for Initial request.
This may help the server to decide which realm the user belong to and
enforce the realm specific authentication policy. Eg. Select algorism.
_________________________________________________________________
Peili Xu
System Engineer Core Network Research & Standard Department
Huawei Technologies Co., Ltd
Email: [EMAIL PROTECTED]
Phone: +86-755-28780808
Website: www.huawei.com
_________________________________________________________________
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Arunachalam
Venkatraman (arunvenk)
Sent: Friday, July 15, 2005 12:23 AM
To: Dale Worley; [email protected]
Subject: RE: [Sip-implementors] proxy servers multiple realm
I believe an initial request may contain credentials using the most
recently offered nonce on a prior call. Nonce is not tied to a single
call or session.
Of course, there is no guarantee that the credentials will be
accepted.
The server may accept the credentials if the nonce lifetime has not
expired and local policy allows it. Or, the server may re-challenge
with
a new nonce. I would suspect that most servers currently do the
latter.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dale
Worley
Sent: Thursday, July 14, 2005 9:16 AM
To: [email protected]
Subject: RE: [Sip-implementors] proxy servers multiple realm
From: Peili Xu [mailto:[EMAIL PROTECTED]
Since the final choice of the realm is decided by user.
Another possible way
is that user can config the associated realm in his terminal.
So that the initial Request can contain the realm information.
In my experience, user agents do not add authorization headers in
initial requests. I believe that this is because the proxy will not
accept an authorization header that does not contain a current nonce,
and the only way for a user agent to get a nonce is from a 407
response.
So there is no benefit in sending an authorization header to a proxy
that one has not recently communicated with, since one cannot include
a
current nonce.
Dale
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
------------------------------
Message: 2
Date: Fri, 15 Jul 2005 06:28:23 -0700 (PDT)
From: sathya shankar <[EMAIL PROTECTED]>
Subject: RE:[Sip-implementors] Query on Hold call
To: [email protected], [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=iso-8859-1
Invite with the same callid is normally considered as
the hold invite.
Sathya Shankar
In what all except the below scenarios the re-INVITE
will be considered
as hold?
in SDP:-
1st scenario is : c= IN IPV4 0.0.0.0
2nd scenario is : m = audio 0
any other scenarios will be considered re-invite as
hold call?
Regards
Pavan reddy.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
------------------------------
Message: 3
Date: Fri, 15 Jul 2005 09:35:15 -0400
From: "Paliakkara, Geo Paul (Geo)" <[EMAIL PROTECTED]>
Subject: RE: [Sip-implementors] Query on Hold call
To: [email protected]
Message-ID:
<[EMAIL PROTECTED]
Content-Type: text/plain; charset="iso-8859-1"
I do not think you can consider Re-INVITE with same call ID as hold
INVIITE. There are many cases you send Re-INVITE other than hold and all
these will have the same call Id.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of sathya
shankar
Sent: Friday, July 15, 2005 9:28 AM
To: [email protected]; [EMAIL PROTECTED]
Subject: RE:[Sip-implementors] Query on Hold call
Invite with the same callid is normally considered as
the hold invite.
Sathya Shankar
In what all except the below scenarios the re-INVITE
will be considered
as hold?
in SDP:-
1st scenario is : c= IN IPV4 0.0.0.0
2nd scenario is : m = audio 0
any other scenarios will be considered re-invite as
hold call?
Regards
Pavan reddy.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
------------------------------
Message: 4
Date: Fri, 15 Jul 2005 09:36:54 -0400
From: Paul Kyzivat <[EMAIL PROTECTED]>
Subject: Re: [Sip-implementors] Query on Hold call
To: [EMAIL PROTECTED]
Cc: "[email protected]"
<[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Setting the port to zero is not a normal way to invoke hold. Instead it
is likely to be interpretted as meaning that the media is not desired or
supported at all.
In reality none of the methods of expressing hold can be unambiguously
understood to mean that. They all may also be used in other cases where
the intent is something other than hold.
Lets discuss the cases:
- 1st scenario is : c= IN IPV4 0.0.0.0
This is the "old" way of doing hold. It is now deprecated for purposes
of conventional hold, but still has other uses. By providing no address
where media may be sent, this insists that no media is desired at the
moment. That may be because this end of the call is on hold or another
reason. It says nothing about what goes in the other direction.
Normally, if the other end does not want to be on hold, it will provide
a valid address. In that case the end on hold may still send medis.
(E.g. "music on hold") to entertain the other party.
As I noted, this is not deprecated for hold, in favor of case 4.
A case where it still may be needed is in some 3pcc call flows. In some
cases there is a B2BUA in the middle setting up the call. It needs to
solicit an offer from one side and offer it to the other side. In some
cases it may want to suggest the media to be used in the call. But it
may not be capable of terminating media itself. In that case it may make
an offer with c= IN IPV4 0.0.0.0. It will be hoping the answer will
contain a media address. This then will be offered to the other party.
For this reason you can see it is important not to respond to an offer
like this with an answer also containing c= IN IPV4 0.0.0.0. (However
that may be necessary in some cases if neither end is currently able to
receive media.)
- 2nd scenario is : m = audio 0
This is used in an answer to refuse a media stream. It is used in an
offer to drop a media stream that had previously been in use. It is not
usually used to indicate hold. The most common use in an offer is in a
reinvite after a stream has previously been refused. There is nothing to
*prevent* you from using this for hold, but it is not common usage and
may confuse some peers.
- 3rd : caller a=inactive, callee a=inactive
inactive says no media should flow in either direction. When a phone is
toggled from active to hold it *could* offer a=inactive if it desires
neither to send nor receive media. But doing so *requires* the far end
to answer with a=inactive, so you then cannot know whether the other end
*desires* to receive media or is itself on hold.
If you use this approach, when you want to go off of hold you should
offer a=sendrecv rather than a=recvonly, because you want to tell the
other end all that you are *willing* to do. If not, it may be difficult
to get out of hold state.
- 4th : caller a=sendonly, callee a=recvonly
This is the currently recommended way of of signaling hold. Note that
rather than "caller" and "callee", this should say "offerer" and
"answerer".
The offer of a=sendonly means that you don't want to receive media, but
you are willing to send media. But it is not a promise of what media you
will send. In a hold scenario you would probably either send nothing,
send beeps, or send music on hold. (That is assuming that the other side
responds with a=recvonly.)
The usual response is "a=recvonly". This is interpretted as meaning that
it is acquessing to the hold, but is ready to go off hold - standing by.
Once in that state, the end that is recvonly could also be put on hold
by its user. (Who is tired of listening to music on hold.) In that case
it could make another offer with a=sendonly or a=inactive. I think the
temptation here would be to offer a=inactive, but I also think that is
not the best choice. I think each end should always indicate what it is
willing to do. So a=sendonly would be a better choice. Then the answer
would probably be a=inactive because that end is only willing to send
but is prevented from responding that. As follows:
A talking to B
A goes on hold: A->B sendonly, B->A recvonly
B goes on hold too: B->A sendonly, A->B inactive
A goes off hold: A->B sendrecv, B->A sendonly
B goes off hold: B->A sendrecv, A->B sendrecv
If, when on hold, an endpoint receives an invite without any offer, it
should always respond with an offer of the maximum set of things it is
willing to do at that time. That is needed in order for 3pcc to work
properly. Don't condition this with what you think the other end is
interested in doing - it may be that you will not end up talking to the
same UA you had previously been talking to.
Paul
SungWoo Lee wrote:
I will draw call flow to make things easier.
A B
m= 1000 |-------------->|
|<--------------| m=2000
<-------------------------->
m=0 |-------------->|
|<--------------| m=2000
Above case, A may think it is on Hold successfully,
getting no RTP from B.
Meanwhile, B still gets RTP from A, because B did not change its RTP
port no.
Thus, it does not affect any to B.
In terms of 4th scenario, it is suitable for a hold situation
where caller wants to send some hold signal(or music)
to callee; Callee may get embarrassed if the caller's voice
suddenly disappeared without any notice.
Sean.
------- Original Message -------
Sender : pavan kumar reddy<[EMAIL PROTECTED]>
Date : 2005-07-15 14:32
Title : Re: Re: [Sip-implementors] Query on Hold call
Hi sung,
2nd scenario is m=audio 0 ->port
To which port,will be sending the media packets if m = audio 0, that
should be considered as hold. Any comments?
can you describe the 4th scenario briefly?
Regards
Pavan Reddy.
On Fri, 15 Jul 2005 SungWoo Lee wrote :
3rd : caller a=inactive, callee a=inactive
4th : caller a=sendonly, callee a=recvonly
I wonder your 2nd scenario is appropriate for hold or not;
It should come with codec negotiation story.
As far as I am concerned, 1st, 3rd and 4th scenarios are all about
hold.
Any comment?
Sean.
------- Original Message -------
Sender : pavan kumar reddy<[EMAIL PROTECTED]>
Date : 2005-07-15 13:42
Title : [Sip-implementors] Query on Hold call
In what all except the below scenarios the re-INVITE will be
considered as hold?
in SDP:-
1st scenario is : c= IN IPV4 0.0.0.0
2nd scenario is : m = audio 0
any other scenarios will be considered re-invite as hold call?
Regards
Pavan reddy.
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
------------------------------
Message: 5
Date: Fri, 15 Jul 2005 09:39:21 -0400
From: Paul Kyzivat <[EMAIL PROTECTED]>
Subject: Re: [Sip-implementors] New offer in 200 OK of INVITE
To: The Rev <[EMAIL PROTECTED]>
Cc: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii; format=flowed
The Rev wrote:
OK, this is clear, but what if ther is no SDP in INVITE and 183
conveys
the SDP offer and PRACK conveys the answer. Can we re-offer in the
200OK
of INVITE.
NO.
If you want to make another offer, you must send an UPDATE.
Or, complete the invite with an ACK and then send a reINVITE with your
new offer.
A more lenient scheme (such as you hint at) was discussed, but rejected.
Paul
In this case this "one offer/answer per transaction" is not
totally clear (since there are two offersr in the INVITE transaction,
(ACK is a new transaction) maybe the same applies for my previous
example since there are 2 offer in the INVITE transaction (ACK PRACK
is
a new transaction). SO I'm still confused.
br
Andras
From: Paul Kyzivat <[EMAIL PROTECTED]>
To: The Rev <[EMAIL PROTECTED]>
CC: [email protected]
Subject: Re: [Sip-implementors] New offer in 200 OK of INVITE
Date: Wed, 13 Jul 2005 14:34:32 -0400
You have to use UPDATE instead.
This was debated at length a long time ago. Basic conclusion was that
you can have at most one offer/answer per transaction.
Paul
The Rev wrote:
Hi,
Can I send new offer in 200OK of INVITE in the following case? Do I
have to use UPDATE instead?
Caller Callee
| |
| |
|(1) INVITE with offer 1 |
|---------------------------->|
| |
| |
|(2) 180 INVITE with answer 1 |
|<----------------------------|
| Require: 100rel |
| |
| |
|(3) PRACK |
|---------------------------->|
| |
| |
|(4) 200 PRACK |
|<----------------------------|
| |
| |
|(5) 200 INVITE with offer 2 |
|<----------------------------|
| |
| |
|(6) ACK with answer 3 |
|---------------------------->|
| |
| |
br
Andras
_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
------------------------------
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
End of Sip-implementors Digest, Vol 28, Issue 28
************************************************
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
