I have a Polycom Trio SIP registered to ASM. It is enabled for ip-softphone/video on the endpoint profile (CM is a managed element). I have SIP trunks from the CM to ASM, In addition, I have SIP trunks from ASM to a Cisco VCS. Registered to the Cisco VCS are h.323 video endpoints. Calls to these h.323 extensions are setup in CM's AAR to route to the SIP trunk in ASM and in ASM there is a dial pattern to send that range to the Cisco VCS. I am able to get audio only calls working and cannot figure out what is missing for why video is not working. Anyone have any ideas on what I can look at?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
SIP Video
- Thread starter wpetilli
- Start date
montyzummer
IS-IT--Management
Yes can you log a traceSM to file and post the .txt and pcap , this should work but impossible to say with seeing some traces.
APSS (SME)
ACSS (SME)
ACIS (UC)
APSS (SME)
ACSS (SME)
ACIS (UC)
- Thread starter
- #4
Awesome, I'll send those over. Is there a trace from CM also needed? I'm not fully clear how the communication path works with a SIP registered endpoint that has a CM endpoint profile. Does the call go straight from the endpoint thru ASM or does it come from CM or both?
Its endpoint to SM to CM. Then CM would send it where it needs. If it were another Polycom video endpoint, then the 2nd leg would look like CM->SM->Polycom.
Now, the Polycom's original SDP should always have video and CM will pass that along if video's enabled on the station.
Now, the Polycom's original SDP should always have video and CM will pass that along if video's enabled on the station.
- Thread starter
- #6
To summarize --
CM 6.3 with SIP Trunk to ASM 6.3 (tcp) -- polycom trio registered as sip endpoint with CM endpoint profile applied. SIP trunk/entity of cisco vcs to ASM.
polycom trio -- 3524@test.blackstone.com calling extension 6356. 6356 is an aar entry in CM that routes to ASM. It appends the test.blackstone.com from CM. There's a route policy and dial pattern for 6356 to terminate at the Cisco VCS entity link. There's an adaptation applied to the cisco vcs entity link with a cisco adapter with odstd=bx.com. This is set to the digit conversion on egress. The goal of that was to have test.blackstone.com converted to bx.com, which the VCS already has a search rule for. The call reaches the VCS and hits the 6356 h.323 video endpoint, but with audio only. Attached is the pcap from ASM. the post after has the other file.
CM 6.3 with SIP Trunk to ASM 6.3 (tcp) -- polycom trio registered as sip endpoint with CM endpoint profile applied. SIP trunk/entity of cisco vcs to ASM.
polycom trio -- 3524@test.blackstone.com calling extension 6356. 6356 is an aar entry in CM that routes to ASM. It appends the test.blackstone.com from CM. There's a route policy and dial pattern for 6356 to terminate at the Cisco VCS entity link. There's an adaptation applied to the cisco vcs entity link with a cisco adapter with odstd=bx.com. This is set to the digit conversion on egress. The goal of that was to have test.blackstone.com converted to bx.com, which the VCS already has a search rule for. The call reaches the VCS and hits the 6356 h.323 video endpoint, but with audio only. Attached is the pcap from ASM. the post after has the other file.
- Thread starter
- #7
well, in the call at 16.16.53.50, the 200 response with SDP from 10.1.130.205 had no H264 parameters.
In the call at 16.16.53, the polycom sent a SDP line
Media Attribute (a): fmtp:100 profile-level-id=640029; packetization-mode=1; max-mbps=245760; max-fs=8196
The return from Cisco in the 180 had:
Media Attribute (a): rtpmap:100 H264/90000
Maybe cisco and polycom ain't jiving on the extra options polycom is sending re: max fram size and whatnot and they only agree on audio.
I don't think it's an avaya problem at all!
In the call at 16.16.53, the polycom sent a SDP line
Media Attribute (a): fmtp:100 profile-level-id=640029; packetization-mode=1; max-mbps=245760; max-fs=8196
The return from Cisco in the 180 had:
Media Attribute (a): rtpmap:100 H264/90000
Maybe cisco and polycom ain't jiving on the extra options polycom is sending re: max fram size and whatnot and they only agree on audio.
I don't think it's an avaya problem at all!
- Thread starter
- #9
I came across this thread... does this line up with what I'm experiencing? I am running VCS 8.6.1
"I would not go past version 8.5.3 on your VCS if you are using SIP trunks (Zones) to Avaya. you will find 8.6 removes the feature that will allow you to limit the size of the SDP length being sent to Avaya. Video requests will not be filtered in the zone once you upgrade to 8.6.
"I would not go past version 8.5.3 on your VCS if you are using SIP trunks (Zones) to Avaya. you will find 8.6 removes the feature that will allow you to limit the size of the SDP length being sent to Avaya. Video requests will not be filtered in the zone once you upgrade to 8.6.
TriniTech87
Technical User
Hey dude check your TLS Settings or check to see if video is enabled if it is a SIP endpoint check the setting to see if video is enabled
- Thread starter
- #12
@kyle-- checked in the units settings and I don't have options to alter those settings.
@Trinitech- video is enabled in the endpoint profile as well as on the device itself.
I am able to get video working if I register this endpoint directly to the Cisco VCS and not ASM. Prefer the ASM route because using VCS search rules get a little messy with sending audio out via Avaya and video locally.
@Trinitech- video is enabled in the endpoint profile as well as on the device itself.
I am able to get video working if I register this endpoint directly to the Cisco VCS and not ASM. Prefer the ASM route because using VCS search rules get a little messy with sending audio out via Avaya and video locally.
TriniTech87
Technical User
Ok you can also see if SIP is using the correct security protocol editing it from TCP to TLS can also work
- Thread starter
- #15
Look in SM Administration part of SMGR. There's a global overall checkbox to the effect of "ignore SDP for call admission control" which is defaulted to "no, don't ignore that".
Then, in "Routing" and "Locations", you have per-location max multimedia bandwidth limits - 2000kbps default.
If I read that right, I'd reckon SM wouldn't let any video >2Mbps using the out of the box configurations without turning that stuff up.
I recall looking at your packet captures a while back and I can't recall if you got the Polycom-->SM-->CM-->SM-->VCS legs all in there, but see where the SDP is getting dropped - did it get in and out of CM properly? If CM wasn't the problem, I'd check into "ignoring SDP in CAC" or cranking the per-call multimedia BW for that location up to see if that might be why SM is not passing along the video in the SDP to the VCS.
Then, in "Routing" and "Locations", you have per-location max multimedia bandwidth limits - 2000kbps default.
If I read that right, I'd reckon SM wouldn't let any video >2Mbps using the out of the box configurations without turning that stuff up.
I recall looking at your packet captures a while back and I can't recall if you got the Polycom-->SM-->CM-->SM-->VCS legs all in there, but see where the SDP is getting dropped - did it get in and out of CM properly? If CM wasn't the problem, I'd check into "ignoring SDP in CAC" or cranking the per-call multimedia BW for that location up to see if that might be why SM is not passing along the video in the SDP to the VCS.
- Status
Similar threads
