>> I think there are also other codecs that could be selected along with
>> single codec, like CN codec. Perhaps a list of codecs, specified by
>> yet an another tag.
>
> I added SOATAG_AUDIO_AUX() for that purpose.
>
> Denis, could you test the attached patch (against 1.12.1)?
What about auxiliary audio - it seems to work fine, but there still problems
with respond to re-INVITE:
send 825 bytes to udp/[192.168.138.60]:5060 at 04:49:40.885611:
INVITE sip:[EMAIL PROTECTED] SIP/2.0
Via: SIP/2.0/UDP 192.168.138.65;rport;branch=z9hG4bK7F4QU3rUmXmUK
Max-Forwards: 70
From: <sip:[EMAIL PROTECTED]>;tag=7a93c1ZSmerrg
To: <sip:[EMAIL PROTECTED]>
Call-ID: 62afc021-989d-1200-f481-8d6be3d4a18d
CSeq: 30761267 INVITE
Contact: <sip:[EMAIL PROTECTED]>
User-Agent: TAU-32.IP v1.1 with sofia-sip/1.12.1
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE,
NOTIFY, REFER, UPDATE
Supported: timer, 100rel
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 260
v=0
o=- 4055417593070913274 8147886360907374363 IN IP4 192.168.138.65
s=-
c=IN IP4 192.168.138.65
t=0 0
m=audio 23000 RTP/AVP 4 8 0 101
a=rtpmap:4 G723/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
...
recv 732 bytes from udp/[192.168.138.60]:5060 at 04:49:50.232295:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.138.65;rport=5060;branch=z9hG4bK7F4QU3rUmXmUK
Record-Route: <sip:192.168.138.60:5060;lr>
From: <sip:[EMAIL PROTECTED]>;tag=7a93c1ZSmerrg
To: <sip:[EMAIL PROTECTED]>;tag=202699017
Call-ID: 62afc021-989d-1200-f481-8d6be3d4a18d
CSeq: 30761267 INVITE
Contact: <sip:[EMAIL PROTECTED]:5060;user=phone;transport=udp>
Server: Cisco ATA 186 v3.1.0 atasip (040211A)
Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER
Content-Type: application/sdp
Content-Length: 199
v=0
o=4000 15814 15814 IN IP4 192.168.138.70
s=ATA186 Call
c=IN IP4 192.168.138.70
t=0 0
m=audio 16384 RTP/AVP 4 101
a=rtpmap:4 G723/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
...
recv 831 bytes from udp/[192.168.138.60]:5060 at 04:49:52.185998:
INVITE sip:[EMAIL PROTECTED] SIP/2.0
Via: SIP/2.0/UDP
192.168.138.60:5060;rport;branch=z9hG4bK38aa6edee6d55bac.3
Via: SIP/2.0/UDP 192.168.138.70:5060
From: sip:[EMAIL PROTECTED];tag=202699017
To: sip:[EMAIL PROTECTED];tag=7a93c1ZSmerrg
Call-ID: 62afc021-989d-1200-f481-8d6be3d4a18d
CSeq: 1 INVITE
Contact: <sip:[EMAIL PROTECTED]:5060;user=phone;transport=udp>
User-Agent: Cisco ATA 186 v3.1.0 atasip (040211A)
Expires: 10
Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER
Record-Route: <sip:192.168.138.60:5060;lr>
Content-Type: application/sdp
Content-Length: 225
v=0
o=4000 16010 16010 IN IP4 192.168.138.70
s=ATA186 Call
c=IN IP4 192.168.138.70
t=0 0
m=audio 16384 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
...
send 811 bytes to udp/[192.168.138.60]:5060 at 04:49:52.194398:
SIP/2.0 200 OK
Via: SIP/2.0/UDP
192.168.138.60:5060;rport=5060;branch=z9hG4bK38aa6edee6d55bac.3
Via: SIP/2.0/UDP 192.168.138.70:5060
Record-Route: <sip:192.168.138.60:5060;lr>
From: sip:[EMAIL PROTECTED];tag=202699017
To: sip:[EMAIL PROTECTED];tag=7a93c1ZSmerrg
Call-ID: 62afc021-989d-1200-f481-8d6be3d4a18d
CSeq: 1 INVITE
Contact: <sip:[EMAIL PROTECTED]>
User-Agent: TAU-32.IP v1.1 with sofia-sip/1.12.1
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE,
NOTIFY, REFER, UPDATE
Supported: timer, 100rel
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 188
v=0
o=- 4055417593070913274 8147886360907374365 IN IP4 192.168.138.65
s=-
c=IN IP4 192.168.138.65
t=0 0
m=audio 23000 RTP/AVP 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
...
The majority problem is that the answer on offer in second round is based on
the last negotiated SDP, but not user supplied
(soa_base_set_params does not increment ss_user_version number in most
cases, which is compared in offer_answer_step).
Unfortunately i have not good idea how to solve this.
In my previous patch soa_sdp_upgrade was called in case if remote version
have been changed:
/* Step B: upgrade local SDP (add m= lines to it) */
....
case generate_answer:
/* Upgrade local SDP based on remote SDP */
if (ss->ss_local_user_version == user_version &&
ss->ss_local_remote_version == remote_version)
break;
if (ss->ss_local_user_version != user_version ||
+ ss->ss_local_remote_version != remote_version ||
soa_sdp_upgrade_is_needed(local, remote)) {
if (local != local0)
*local0 = *local, local = local0;
SU_DEBUG_7(("soa_static(%p, %s): %s\n", ss, by,
"upgrade with remote description"));
soa_sdp_upgrade(ss, tmphome, local, user, remote);
}
...
but that is of course is not good decision.
May be there should be more precision test to increment ss_user_version or
may be it always should be incremented when user pass SDP to SOA?
In last case i think there should not be a problems: if the user want to use
last negotiated session parameters, there no need to pass session
description to SOA again.
Best regards,
Legostayev Denis
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
