Subject: [Sipping] SIP/SDP "hold and resume"

From: Antonio Corghi <[email-masked]>
Date: Mon, 14 Jan 2008 11:22:06 +0100

Hi all,

	we're facing some interop issues between two different SIP  
implementations on the "music on hold" scenario.

Below you can find what's happening, after the basic call has been  
properly activated:

1) UA1 places on hold UA2 by sending Invite with SDP "a=inactive" with  
connection address "0.0.0.0"
2) UA2 replies 200OK with SDP answer with "a=inactive" and connection  
address "0.0.0.0" (according to RFC3264)
3) UA1 issues a new Invite to UA2 in order to redirect UA2 to the  
"Music -on-hold" server. This invite does NOT contain SDP (will be  
included in the ACK)
4) UA2 replies 200OK with SDP answer with "a=inactive" and connection  
address "0.0.0.0" (according to RFC3264)

Both the UAs are stuck on hold.

I found that last paragraph of section 5.3 in draft "draft-ietf- 
sipping-sip-offeranswer-04.txt" suggests that UA2, at step "4", should  
answer with "a=sendrecv, even if it had previously been forced to  
answer something else".

Can anyone help me on this topic?

Thanks in advance,
Antonio Corghi

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Jan 2008 07:51:23 -0500

> connection address "0.0.0.0"

This is a bit of overkill, using both inactive and 0.0.0.0.
It probably thinks this is easier that just trying inactive first and 
failing over to c=0.0.0.0 if that doesn't work.

> 3) UA1 issues a new Invite to UA2 in order to redirect UA2 to the "Music 
> -on-hold" server. This invite does NOT contain SDP (will be included in 
> the ACK)

A classic problem!

> I found that last paragraph of section 5.3 in draft 
> "draft-ietf-sipping-sip-offeranswer-04.txt" suggests that UA2, at step 
> "4", should answer with "a=sendrecv, even if it had previously been 
> forced to answer something else".
> 

Well, I'm the author of that. Step 4 isn't an answer, it is an offer. 
And to avoid the "stuck on hold" you are seeing it should indeed be 
offering based on its own desired state rather than what it thinks UA1 
wants.

	Paul

---

From: Antonio Corghi <[email-masked]>
Date: Mon, 14 Jan 2008 23:26:24 +0100

Hi Paul,

	first of all, many thanks for your immediate answer.

Sorry, but I do not understand your last point. UA1 placed on hold UA2  
by sending Invite with the "inactive" attribute. Now UA1 is trying to  
modify its own state by issuing an empty Invite. If UA2 sends out an  
SDP offer according to its own local desired state, maybe it (UA2) is  
going to send out an "inactive" offer. And this behaviour would be the  
reason of the stuck on hold state, as UA1 has to reply with an SDP  
inactive answer.

IMHO the only way to avoid the "stuck on hold" is to require that UA2  
should issue a sendrecv offer, as your draft specifies.

Thanks in advance.

Rgds,
	Antonio

On Jan 14, 2008, at 1:51 PM, Paul Kyzivat wrote:

>> 1) UA1 places on hold UA2 by sending Invite with SDP "a=inactive"  
>> with connection address "0.0.0.0"
>
> It probably thinks this is easier that just trying inactive first  
> and failing over to c=0.0.0.0 if that doesn't work.
>
>> 2) UA2 replies 200OK with SDP answer with "a=inactive" and  
>> connection address "0.0.0.0" (according to RFC3264)
>> 4) UA2 replies 200OK with SDP answer with "a=inactive" and  
>> connection address "0.0.0.0" (according to RFC3264)
>
> A classic problem!
>
>> sipping-sip-offeranswer-04.txt" suggests that UA2, at step "4",  
>> should answer with "a=sendrecv, even if it had previously been  
> Well, I'm the author of that. Step 4 isn't an answer, it is an  
> offer. And to avoid the "stuck on hold" you are seeing it should  
> indeed be offering based on its own desired state rather than what  
> it thinks UA1 wants.
>
> 	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Jan 2008 17:45:18 -0500

Antonio Corghi wrote:
> Sorry, but I do not understand your last point.

Sorry about that. I'll try to clarify.

> UA1 placed on hold UA2 
> modify its own state by issuing an empty Invite.

Right.

One of my points (which might have been confusing) is just that you said 
what UA2 sends in response to this is an *answer*. It isn't an answer 
because there hasn't been an offer yet. What UA2 sends in response to 
the empty invite is an *offer*.

> If UA2 sends out an SDP 
> offer according to its own local desired state, maybe it (UA2) is going 
> to send out an "inactive" offer. And this behaviour would be the reason 
> of the stuck on hold state, as UA1 has to reply with an SDP inactive 
> answer.
> 

We are actually in agreement. UA1 previously put UA2 on hold. But UA2 
didn't *want* to be on hold. Then UA1 sent an offerless reinvite. So UA2 
should send an offer containing what it *wants*, which is sendrecv, just 
as you think it should.

	Paul

>>> "draft-ietf-sipping-sip-offeranswer-04.txt" suggests that UA2, at 
>>> step "4", should answer with "a=sendrecv, even if it had previously 
>>> been forced to answer something else".