Paul stated a hold scneario 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
Is this a common interpretation? I never percieved the directions as
having a half duplex state in this manner. I always viewed the
directional attribute in the answer as acknowledging the direction in
the offer. For example acceptable answers to offers are:
OFFER: sendonly
ANSWER: recvonly
OFFER: inactive
ANSWER: inactive
In Paul's example above, if party A is streaming MOH to B, shouldn't B
be expected to receive te RTP insomuch as that A can at least receive
RTCP receiver reports from B? Again, without taking a half-duplex
directional state perspective, on the surface party B's subsequent
sendonly one could have interpretted to imply B had instead intended to
transmit the MOH locally than have it generated at A. Am I alone in
this thinking?
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
